From 8dfedb0296ec628abdf29d0df351e20c2562ff9e Mon Sep 17 00:00:00 2001 From: Ralph Amissah Date: Sun, 20 Dec 2009 20:17:01 -0500 Subject: debian/data moved dir to accomodate v1 dir structure --- .../dfsg/_sisu/skin/doc/skin_debian.rb | 84 ---- .../dfsg/debian_constitution_v1.2.adjusted.sst | 505 -------------------- .../dfsg/debian_constitution_v1.2.sst | 502 -------------------- .../dfsg/debian_constitution_v1.2~da.sst | 504 -------------------- .../dfsg/debian_constitution_v1.2~de.sst | 506 -------------------- .../dfsg/debian_constitution_v1.2~es.sst | 518 --------------------- .../dfsg/debian_constitution_v1.2~fr.sst | 509 -------------------- .../dfsg/debian_constitution_v1.3.adjusted.sst | 508 -------------------- .../dfsg/debian_constitution_v1.3.sst | 508 -------------------- .../dfsg/debian_constitution_v1.3~da.sst | 517 -------------------- .../dfsg/debian_constitution_v1.3~de.sst | 505 -------------------- .../dfsg/debian_social_contract_v1.1.sst | 140 ------ .../dfsg/debian_social_contract_v1.1~da.sst | 142 ------ .../dfsg/debian_social_contract_v1.1~de.sst | 142 ------ .../dfsg/debian_social_contract_v1.1~es.sst | 140 ------ .../dfsg/debian_social_contract_v1.1~fi.sst | 142 ------ .../dfsg/debian_social_contract_v1.1~fr.sst | 140 ------ .../dfsg/debian_social_contract_v1.1~it.sst | 132 ------ 18 files changed, 6144 deletions(-) delete mode 100644 debian/data/sisu_markup_samples/dfsg/_sisu/skin/doc/skin_debian.rb delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.adjusted.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~da.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~de.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~es.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~fr.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.adjusted.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~da.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~de.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~da.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~de.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~es.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fi.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fr.sst delete mode 100644 debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~it.sst (limited to 'debian/data/sisu_markup_samples/dfsg') diff --git a/debian/data/sisu_markup_samples/dfsg/_sisu/skin/doc/skin_debian.rb b/debian/data/sisu_markup_samples/dfsg/_sisu/skin/doc/skin_debian.rb deleted file mode 100644 index efa0d1bd..00000000 --- a/debian/data/sisu_markup_samples/dfsg/_sisu/skin/doc/skin_debian.rb +++ /dev/null @@ -1,84 +0,0 @@ -=begin - * Name: SiSU information Structuring Universe - Serialised information, Structured Units - * Author: Ralph@Amissah.com - * http://www.jus.uio.no/sisu - * http://www.jus.uio.no/sisu/SiSU/download - * Description: Document skin for SiSU descriptive pages, ... - * License: Same as SiSU see http://www.jus.uio.no/sisu - * Notes: Site default appearance variables set in defaults.rb - Generic site wide modifications set here scribe_skin.rb, and this file required by other "scribes" instead of defaults.rb -=end -module SiSU_Viz - require "#{SiSU_lib}/defaults" # - class Skin - #% path - def path_root - './sisu/' # the only parameter that cannot be changed here - end - def path_rel - '../' - end - #% url - def url_root_http - 'http://www.jus.uio.no/sisu' - end - def url_home - 'http://www.debian.org/' - end - def url_site # used in pdf header - 'http://www.debian.org' - end - def url_txt # text to go with url usually stripped url - 'www.debian.org' - end - def url_home_url - '../index.html' - end - #% color - def color_band1 - '"#ffffff"' - end - def color_band2 - '"#ffffff"' - end - #% txt - def txt_hp - ' Debian' - end - def txt_home - 'Debian' - end - #% icon - def icon_home_button - 'debian_home.png' - end - def icon_home_banner - home_button - end - #% banner - def banner_home_button - %{
#{png_home}
\n} - end - def banner_home_and_index_buttons - %{
#{png_home}#{table_close}
 This text sub- 
 Table of Contents #{table_close}		 #{table_close}} - end - def banner_band - %{
#{png_home}#{table_close}} - end - end - class TeX - def header_center - "\\chead{\\href{#{@vz.url_site}/}{www.debian.org}}" - end - def home_url - "\\href{#{@vz.url_site}/}{www.debian.org}" - end - def home - "\\href{#{@vz.url_site}/}{Debian}" - end - def owner_chapter - "Document owner details" - end - end -end - diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.adjusted.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.adjusted.sst deleted file mode 100644 index 0f29c9f9..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.adjusted.sst +++ /dev/null @@ -1,505 +0,0 @@ -% SiSU 0.38 - -@title: Debian Constitution - -@subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2003-10-29 - -@date: 2003-10-29 - -@language.document: English - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{Debian Project}http://www.debian.org/ -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Site map}http://www.debian.org/sitemap -{Search}http://search.debian.org/ -{License}http://www.debian.org/license - -@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo http://www.debian.org/logos/ are trademarks of Software in the Public Interest, Inc. - -@prefix: This Document is Superseded by Version 1.3.
This version 1.2 was taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.
Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2.adjusted.sst,v 1.2 2006/05/24 03:37:02 ralph Exp $ - -:A~ Debian Constitution - -:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] - -1~pre [Prefix]-# - -Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998. - -1~ 1. Introduction - -/{The Debian Project is an association of individuals who have made common cause to create a free operating system.}/ - -This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process. - -1~ 2. Decision-making bodies and individuals - -Each decision in the Project is made by one or more of the following: - -_1 1. The Developers, by way of General Resolution or an election; - -_1 2. The Project Leader; - -_1 3. The Technical Committee and/or its Chairman; - -_1 4. The individual Developer working on a particular task; - -_1 5. Delegates appointed by the Project Leader for specific tasks; - -_1 6. The Project Secretary. - -Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. /{In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.}/ - -2~ 2.1 General rules - -_1 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. - -_1 2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. - -_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly. - -1~ 3 Individual Developers - -2~ 3.1 Powers - -An individual Developer may - -_1 1. make any technical or nontechnical decision with regard to their own work; - -_1 2. propose or sponsor draft General Resolutions; - -_1 3. propose themselves as a Project Leader candidate in elections; - -_1 4. vote on General Resolutions and in Leadership elections. - -2~ 3.2 Composition and appointment - -_1 1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile. - -_1 2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. /{If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.}/ - -2~ 3.3 Procedure - -Developers may make these decisions as they see fit. - -1~ 4. The Developers by way of General Resolution or election - -2~ 4.1 Powers - -Together, the Developers may: - -_1 1. Appoint or recall the Project Leader. - -_1 2. Amend this constitution, provided they agree with a 3:1 majority. - -_1 3. Override any decision by the Project Leader or a Delegate. - -_1 4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority. - -_1 5. Issue, supersede and withdraw nontechnical policy documents and statements. - -These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. - -They may also include position statements about issues of the day. - -_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes. - -_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines. - -_2 3. A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution. - -_1 6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.) - -2~ 4.2 Procedure - -_1 1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. - -_1 2. Delaying a decision by the Project Leader or their Delegate: - -_2 1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see s4.1(3). - -_2 2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). - -_2 3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. - -_2 4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. - -_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted. - -_1 3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. - -_1 4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. - -_1 5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there. - -_1 6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes. - -_1 7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded. - -1~ 5. Project Leader - -2~ 5.1 Powers - -The {Project Leader}http://www.debian.org/devel/leader may: - -_1 1. Appoint Delegates or delegate decisions to the Technical Committee. - -_1 The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. - -_1 Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility. - -_1 2. Lend authority to other Developers. - -_1 The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question. - -_1 3. Make any decision which requires urgent action. - -_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline. - -_1 4. Make any decision for whom noone else has responsibility. - -_1 5. Propose draft General Resolutions and amendments. - -_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) - -_1 7. Use a casting vote when Developers vote. - -_1 The Project Leader also has a normal vote in such ballots. - -_1 8. Vary the discussion period for Developers' votes (as above). - -_1 9. Lead discussions amongst Developers. - -_1 The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. - -_1 10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.) - -2~ 5.2 Appointment - -_1 1. The Project Leader is elected by the Developers. - -_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately. - -_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader. - -_1 4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary. - -_1 5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. - -_1 6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. - -_1 7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is "None Of The Above". - -_1 8. The Project Leader serves for one year from their election. - -2~ 5.3 Procedure - -The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. - -Where practical the Project Leader should informally solicit the views of the Developers. - -The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader. - -1~ 6. Technical committee - -2~ 6.1 Powers - -The {Technical Committee}http://www.debian.org/devel/tech-ctte may: - -_1 1. Decide on any matter of technical policy. - -_1 This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).) - -_1 2. Decide any technical matter where Developers' jurisdictions overlap. - -_1 In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter. - -_1 3. Make a decision when asked to do so. - -_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it. - -_1 4. Overrule a Developer (requires a 3:1 majority). - -_1 The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. - -_1 5. Offer advice. - -_1 The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee. - -_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.) - -_1 7. Appoint the Chairman of the Technical Committee. - -_1 The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. - -_1 8. The Chairman can stand in for the Leader, together with the Secretary - -_1 As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. - -2~ 6.2 Composition - -_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. - -_1 2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. - -_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. - -_1 4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. - -_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. - -2~ 5.3 Procedure - -_1 1. The Technical Committee uses the Standard Resolution Procedure. - -_1 A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. - -_1 2. Details regarding voting - -_1 The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote). - -_1 3. Public discussion and decision-making. - -_1 Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee. - -_1 4. Confidentiality of appointments. - -_1 The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public. - -_1 5. No detailed design work. - -_1 The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. - -_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. - -_1 /{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/ - -_1 6. Technical Committee makes decisions only as last resort. - -_1 The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. - -1~ 7. The Project Secretary - -2~ 7.1 Powers - -The {Secretary:}http://www.debian.org/devel/secretary - -_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution. - -_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee. - -_1 If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. - -_1 3. Adjudicates any disputes about interpretation of the constitution. - -_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time. - -2~ 7.2 Appointment - -The Project Secretary is appointed by the Project Leader and the current Project Secretary. - -If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary. - -If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary. - -The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed. - -2~ 7.3 Procedure - -The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers. - -When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. - -1~ 8. The Project Leader's Delegates - -2~ 8.1 Powers - -The Project Leader's Delegates: - -_1 1. have powers delegated to them by the Project Leader; - -_1 2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. - -2~ 8.2 Appointment - -The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made. - -2~ 8.3 Procedure - -Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. - -1~ 9. Software in the Public Interest - -{SPI}http://www.spi-inc.org/ and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers. - -2~ 9.1 Authority - -_1 1. SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort. - -_1 2. Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules. - -_1 3. Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf. - -2~ 9.2 Management of property for purposes related to Debian - -Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs. - -SPI have made the following undertakings: - -_1 1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian. - -_1 2. Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section. - -_1 3. SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers. - -_1 4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader. - -_1 5. SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority. - -_1 6. SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian. - -1~a A. Standard Resolution Procedure - -These rules apply to communal decision-making by committees and plebiscites, where stated above. - -2~a1 A.1. Proposal - -The formal procedure begins when a draft resolution is proposed and sponsored, as required. - -2~a1a A.1 Discussion and Amendment - -_1 1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. - -_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. - -_1 3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. - -_1 4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).) - -_1 5. The proposer or a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals. - -_1 6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted. - -2~a2 A.2. Calling for a vote - -_1 1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. - -_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. - -_1 3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). - -_1 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. - -2~a3 A.3. Voting procedure - -_1 1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). - -_1 2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. - -_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise. - -_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure. - -2~a4 A.4. Withdrawing resolutions or unaccepted amendments - -The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already. - -A sponsor of a resolution or amendment (unless it has been accepted) may withdraw. - -If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires. - -2~a5 A.5. Expiry - -If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. - -The secretary may also include suggestions on how to proceed, if appropriate. - -2~a6 A.6. Vote Counting - -_1 1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes. - -_1 2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. - -_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. - -_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. - -_2 2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). - -_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. - -_1 4. From the list of undropped options, we generate a list of pairwise defeats. - -_1 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A). - -_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats. - -_1 1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C. - -_1 6. We construct the Schwartz set from the set of transitive defeats. - -_2 1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A. - -_1 7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5. - -_2 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). - -_2 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat. - -_1 8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. - -!_ Note: -Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. - -/{When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.}/ - -2~b B. Use of language and typography - -The present indicative ('is', for example) means that the statement is a rule in this constitution. 'May' or 'can' indicates that the person or body has discretion. 'Should' means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.sst deleted file mode 100644 index e69d9eab..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2.sst +++ /dev/null @@ -1,502 +0,0 @@ -% SiSU 0.38 - -@title: Debian Constitution - -@subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2003-10-29 - -@date: 2003-10-29 - -@language.document: English - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debian Constitution - -:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] - -1~pre [Prefix]-# - -Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998. - -1~ Introduction - -/{The Debian Project is an association of individuals who have made common cause to create a free operating system.}/ - -This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process. - -1~ Decision-making bodies and individuals - -Each decision in the Project is made by one or more of the following: - -# The Developers, by way of General Resolution or an election; - -# The Project Leader; - -# The Technical Committee and/or its Chairman; - -# The individual Developer working on a particular task; - -# Delegates appointed by the Project Leader for specific tasks; - -# The Project Secretary. - -Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. /{In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.}/ - -2~ General rules - -# Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. - -# A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. - -# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly. - -1~ Individual Developers - -2~ Powers - -An individual Developer may - -# make any technical or nontechnical decision with regard to their own work; - -# propose or sponsor draft General Resolutions; - -# propose themselves as a Project Leader candidate in elections; - -# vote on General Resolutions and in Leadership elections. - -2~ Composition and appointment - -# Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile. - -# The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. /{If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.}/ - -2~ Procedure - -Developers may make these decisions as they see fit. - -1~ The Developers by way of General Resolution or election - -2~ Powers - -Together, the Developers may: - -# Appoint or recall the Project Leader. - -# Amend this constitution, provided they agree with a 3:1 majority. - -# Override any decision by the Project Leader or a Delegate. - -# Override any decision by the Technical Committee, provided they agree with a 2:1 majority. - -# Issue, supersede and withdraw nontechnical policy documents and statements. - -These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. - -They may also include position statements about issues of the day. - -_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes. - -_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines. - -_# A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution. - -# Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.) - -2~ Procedure - -# The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. - -# Delaying a decision by the Project Leader or their Delegate: - -_# If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see s4.1(3). - -_# If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). - -_# If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. - -_# If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. - -_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted. - -# Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. - -# The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. - -# Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there. - -# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes. - -# Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded. - -1~ Project Leader - -2~ Powers - -The {Project Leader}http://www.debian.org/devel/leader may: - -# Appoint Delegates or delegate decisions to the Technical Committee. - -The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. - -Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility. - -# Lend authority to other Developers. - -The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question. - -# Make any decision which requires urgent action. - -This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline. - -# Make any decision for whom noone else has responsibility. - -# Propose draft General Resolutions and amendments. - -# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) - -# Use a casting vote when Developers vote. - -The Project Leader also has a normal vote in such ballots. - -# Vary the discussion period for Developers' votes (as above). - -# Lead discussions amongst Developers. - -The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. - -# Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.) - -2~ Appointment - -# The Project Leader is elected by the Developers. - -# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately. - -# For the following three weeks any Developer may nominate themselves as a candidate Project Leader. - -# For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary. - -# The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. - -# The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. - -# The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is "None Of The Above". - -# The Project Leader serves for one year from their election. - -2~ Procedure - -The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. - -Where practical the Project Leader should informally solicit the views of the Developers. - -The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader. - -1~ Technical committee - -2~ Powers - -The {Technical Committee}http://www.debian.org/devel/tech-ctte may: - -# Decide on any matter of technical policy. - -This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).) - -# Decide any technical matter where Developers' jurisdictions overlap. - -In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter. - -# Make a decision when asked to do so. - -Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it. - -# Overrule a Developer (requires a 3:1 majority). - -The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. - -# Offer advice. - -The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee. - -# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.) - -# Appoint the Chairman of the Technical Committee. - -The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. - -# The Chairman can stand in for the Leader, together with the Secretary - -As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. - -2~ Composition - -# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. - -# When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. - -# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. - -# When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. - -# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. - -2~ Procedure - -# The Technical Committee uses the Standard Resolution Procedure. - -A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. - -# Details regarding voting - -The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote). - -# Public discussion and decision-making. - -Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee. - -# Confidentiality of appointments. - -The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public. - -# No detailed design work. - -The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. - -The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. - -/{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/ - -# Technical Committee makes decisions only as last resort. - -The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. - -1~ The Project Secretary - -2~ Powers - -The {Secretary:}http://www.debian.org/devel/secretary - -# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution. - -# Can stand in for the Leader, together with the Chairman of the Technical Committee. - -If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. - -# Adjudicates any disputes about interpretation of the constitution. - -# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time. - -2~ Appointment - -The Project Secretary is appointed by the Project Leader and the current Project Secretary. - -If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary. - -If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary. - -The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed. - -2~ Procedure - -The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers. - -When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. - -1~ The Project Leader's Delegates - -2~ Powers - -The Project Leader's Delegates: - -# have powers delegated to them by the Project Leader; - -# may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. - -2~ Appointment - -The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made. - -2~ Procedure - -Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. - -1~ Software in the Public Interest - -{SPI}http://www.spi-inc.org/ and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers. - -2~ Authority - -# SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort. - -# Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules. - -# Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf. - -2~ Management of property for purposes related to Debian - -Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs. - -SPI have made the following undertakings: - -# SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian. - -# Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section. - -# SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers. - -# SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader. - -# SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority. - -# SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian. - -1~a A. Standard Resolution Procedure - -These rules apply to communal decision-making by committees and plebiscites, where stated above. - -2~a1 A.1. Proposal - -The formal procedure begins when a draft resolution is proposed and sponsored, as required. - -2~a1a A.1 Discussion and Amendment - -# Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. - -# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. - -# If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. - -# If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).) - -# The proposer or a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals. - -# The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted. - -2~a2 A.2. Calling for a vote - -# The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. - -# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. - -# The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). - -# The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. - -2~a3 A.3. Voting procedure - -# Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). - -# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. - -# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise. - -# In cases of doubt the Project Secretary shall decide on matters of procedure. - -2~a4 A.4. Withdrawing resolutions or unaccepted amendments - -The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already. - -A sponsor of a resolution or amendment (unless it has been accepted) may withdraw. - -If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires. - -2~a5 A.5. Expiry - -If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. - -The secretary may also include suggestions on how to proceed, if appropriate. - -2~a6 A.6. Vote Counting - -# Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes. - -# If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. - -# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. - -_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. - -_# An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). - -_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. - -# From the list of undropped options, we generate a list of pairwise defeats. - -_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A). - -# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats. - -_# An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C. - -# We construct the Schwartz set from the set of transitive defeats. - -_# An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A. - -# If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5. - -_# A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). - -_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat. - -# If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. - -/{Note}/: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. - -/{When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.}/ - -1~b B. Use of language and typography - -The present indicative ('is', for example) means that the statement is a rule in this constitution. 'May' or 'can' indicates that the person or body has discretion. 'Should' means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~da.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~da.sst deleted file mode 100644 index c8abacb8..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~da.sst +++ /dev/null @@ -1,504 +0,0 @@ -% SiSU 0.38 - -@title: Debians vedtægter - -@subtitle: Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3] - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2003-10-29 - -@date: 2003-10-29 - -@language.document: Danish - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).
"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.
Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2~dk.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debians vedtægter - -:B~ Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3] - -1~pre [Prefix]-# - -Version 1.2 blev godkendt den 29. oktober 2003. Erstatter version 1.1 som blev godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998. - -1~1 §1. Introduktion - -Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem. - -Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen. - -1~2 §2. Beslutningsdygtige organer og -personer - -Enhver beslutning i projektet er omfattet af en eller flere af følgende: - -# Udviklerne, via en fælles resolution eller et valg; - -# Projektlederen; - -# Den tekniske komité og/eller dennes formand; - -# Den individuelle udvikler som arbejder med en bestemt opgave; - -# Delegater udnævnt af projektlederen til at varetage særlige opgaver; - -# Projektsekretæren. - -Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere. - -2~2.1 §2.1. Generelle regler - -# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne. - -# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat. - -# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette. - -1~3 §3. Individuelle udviklere - -2~3.1 §3.1. Fuldmagt - -En individuel udvikler kan - -# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde; - -# foreslå og støtte udkast til generelle resolutioner; - -# foreslå sig selv som kandidat til projektleder i valg; - -# stemme på generelle resolutioner og i ledervalg. - -2~3.2 §3.2. Sammensætning og udnævnelse - -# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt. - -# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se §4.1(3) og §4.2. - -2~3.3 §3.3. Fremgangsmåder - -Udviklerne kan foretage disse beslutninger efter eget skøn. - -1~4 §4. Udviklerne via generel resolution eller et valg - -2~4.1 §4.1. Fuldmagt - -Udviklerne kan sammen: - -# Udnævne eller afsætte projektlederen. - -# Ændre disse vedtægter med et 3:1-flertal. - -# Ophæve enhver beslutning taget af projektlederen eller en delegat. - -# Ophæve enhver beslutning taget af den tekniske komité, såfremt de er enige med et 2:1-flertal. - -# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer. - -Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til. - -Det kan også være stillingtagen til aktuelle emner. - -_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål. - -_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software. - -_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter. - -# Træffe beslutninger sammen med projektlederen og SPI om forvaltede ejendele til formål der har relation til Debian. (Se §9.1). - -2~4.1 §4.2. Fremgangsmåde - -# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité. - -# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater: - -_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se §4.1(3). - -_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette). - -_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen. - -_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning. - -_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt. - -# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge. - -# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q. - -# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den. - -# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer. - -# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke. - -1~5 §5. Projektlederen - -2~5.1 §5.1. Fuldmagt - -Projektlederen kan: - -# Udnævne delegater eller uddelegere beslutninger til den tekniske komité. - -Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité. - -Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage. - -# Give hjemmel til andre udviklere. - -Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning. - -# Foretage beslutninger som kræver omgående handling. - -Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist. - -# Foretage beslutninger som ingen andre har ansvaret for. - -# Fremstille udkast til generelle resolutioner og ændringsforslag. - -# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se §6.2.) - -# Afgive en afgørende stemme i udviklernes afstemninger. - -Projektlederen har også almindelig stemmeret i sådanne afstemninger. - -# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor). - -# Lede diskussioner blandt udviklerne. - -Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter. - -# Tage beslutninger sammen med SPI, der vedrører ejendele som administreres til formål der vedrører Debian. (Se §9.1.) - -2~5.2 §5.2. Udnævnelse - -# Projektlederen vælges af udviklerne. - -# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående. - -# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat. - -# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange. - -# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet. - -# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange. - -# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit §A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§4.2), og standardvalget er Ingen af de nævnte. - -# Projektlederen vælges for et år ad gangen. - -2~5.3 §5.3. Fremgangsmåde - -Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne. - -Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter. - -Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder. - -1~6 §6. Teknisk komité - -2~6.1 §6.1. Fuldmagt - -Den tekniske komité kan: - -# Træffe beslutninger om tekniske retningslinier. - -Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se §6.3(5).) - -# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper. - -I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen. - -# Træffe en beslutning når den bliver bedt om at gøre dette. - -Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den. - -# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal) - -Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes. - -# Give råd. - -Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter. - -# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se §6.2.) - -# Udnævne formanden for den tekniske komité. - -Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i §A.6 i de generelle resolutionsprocedurer. - -# Formanden kan vikariere for lederen, sammen med sekretæren - -Som beskrevet i §7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder. - -2~6.2 §6.2. Sammensætning - -# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer. - -# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej. - -# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks. - -# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse. - -# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité. - -2~6.3 §6.3. Fremgangsmåde - -# Den tekniske komité anvender den generelle resolutionsprocedure. - -Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to. - -# Detaljerede afstemningoplysninger - -Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret). - -# Offentlig diskussion og afgørelser - -Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen. - -# Fortrolighed ved udnævnelser - -Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres. - -# Ikke et detaljeret udviklingsarbejde - -Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora. - -Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder. - -Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde. - -# Den teknisk komité træffer kun afgørelser som en sidste udvej - -Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette. - -1~7 §7. Projektsekretæren - -2~7.1 §7.1. Fuldmagt - -Sekretæren: - -# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne. - -# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité. - -Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette. - -# Dømmer i stridigheder om tolkning af vedtægterne. - -# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage. - -2~7.2 §7.2. Udnævnelse - -Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær. - -Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede SPI's bestyrelse (se §9.1) om at udnævne en ny sekretær. - -Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær. - -Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig. - -2~7.3 §7.3. Fremgangsmåde - -Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne. - -Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne. - -1~8 §8. Projektlederens delegater - -2~8.1 §8.1. Fuldmagt - -Projektlederens delegater: - -# har fået uddelegeret en fuldmagt fra projektlederen; - -# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab. - -2~8.2 §8.2. Udnævnelse - -Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat. - -2~8.3 §8.3. Fremgangsmåde - -Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus. - -1~9 §9. Software in the Public Interest ("Software i offentlighedens interesse") - -SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder. Debians udviklere er pt. medlemmer af SPI i kraft af deres hverv som udviklere. - -2~9.1 §9.1. Fuldmagt - -# SPI har ingen fuldmagt hvad angår Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger foretaget af Debian som vedrører ejendele der administreres af SPI, kan kræve at SPI handler udenfor sin juridiske fuldmagt, og Debians vedtægter kan af og til gøre SPI til en afgørende myndighed, som en sidste udvej. - -# Debian har ingen bestemmende kontrol over SPI, bortset fra anvendelse af visse ejendele som beskrevet nedenfor, selvom Debians udviklere kan få fuldmagt indenfor SPI efter SPI's regler. - -# Debians udviklere er ikke repræsentanter for, eller ansat af, SPI, eller af personer med fuldmagt i Debian-projektet. En person der handler som udvikler, gør dette som et individ på egne vegne. - -2~9.2 §9.2. Administration af ejendele til formål som vedrører Debian - -Da Debian ikke har fuldmagt til at forvalte penge eller ejendele, skal donationer til Debian-projektet gives til SPI, som håndterer den slags. - -SPI har påtaget sig følgende: - -# SPI vil forvalte penge, varemærker, andre konkrete ejendele og forretninger til formål som vedrører Debian. - -# Sådanne ejendele vil der blive holdt særskilt regnskab for og blive indsat i en fond med det formål, udvalgt af Debian og SPI i henhold til denne paragraf. - -# SPI vil ikke afhænde eller anvende ejendele, de administrerer for Debian, uden samtykke med Debian, som kan gives af projektlederen eller via en generel resolution blandt udviklerne. - -# SPI vil overveje anvendelse og/eller afhændelse af ejendele de administrerer for Debian, når de bliver bedt om det af projektlederen. - -# SPI vil anvende eller afhænde ejendele som administreres for Debian når de bliver bedt om at gøre dette, via en generel resolution blandt udviklerne, såfremt dette er foreneligt med SPI's juridiske fuldmagt. - -# SPI vil via elektronisk post til en af Debian-projektets postlister, gør opmærksom på når ejendele, der administreres for Debian, anvendes eller afhændes. - -1~a A. Generel resolutionsprocedure - -Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor. - -2~a1 A.1. Forslag - -Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet. - -2~a1a A.1. Diskussion og ændring - -# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag. - -# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres. - -# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette. - -# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).) - -# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige. - -# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen. - -2~a2 A.2. Afstemning - -# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået. - -# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag. - -# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4). - -# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret. - -2~a3 A.3. Afstemningsprocedure - -# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt). - -# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav. - -# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet. - -# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål. - -2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag - -Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det. - -En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret). - -Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber. - -2~a5 A.5. Udløb - -Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage. - -Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat. - -2~a6 A.6. Stemmeoptælling - -# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen. - -# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning. - -# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning. - -_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B. - -_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A). - -_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1. - -# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag. - -_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A). - -# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag. - -_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C. - -# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt. - -_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt. - -# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5. - -_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B). - -_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag. - -# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen. - -Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable. - -Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes. - -1~b B. Brug af sprog og typografi - -Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde. - -Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~de.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~de.sst deleted file mode 100644 index 70e1a523..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~de.sst +++ /dev/null @@ -1,506 +0,0 @@ -% SiSU 0.38 - -@title: Debian-Verfassung - -@subtitle: Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3] - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2003-10-29 - -@date: 2003-10-29 - -@language.document: German - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.de.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.
Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich. - -% @rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2~de.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debian-Verfassung - -:B~ Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3] - -1~pre [Prefix]-# - -Dies ist die am 29. Oktober 2003 ratifizierte Version 1.2. Sie ersetzt die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt. - -1~ Einleitung - -/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystem zu ihrem gemeinsamen Anliegen gemacht haben.}/ - -Dieses Dokument beschreibt die Organisationsstruktur für formelle Entscheidungsfindung innerhalb des Projekts. Es beschreibt nicht die Ziele des Projekts oder wie es diese erreicht, und es enthält keine Richtlinien außer denen, die sich direkt auf den Prozess der Entscheidungsfindung beziehen. - -1~ Entscheidungsfindende Organe und Einzelpersonen - -Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen: - -# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl. - -# Dem Projektleiter; - -# Dem Technischen Ausschuss und/oder seinem Vorsitzenden; - -# Dem an einer einzelnen Aufgabe arbeitenden Entwickler; - -# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten; - -# Dem Projekt-Schriftführer. - -Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse dieser Organe, ihre Zusammensetzung und Ernennung und das Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person oder eines Organs können der Überwachung und/oder Einschränkung durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen. - -2~ Allgemeine Vorschriften - -# Nichts in dieser Verfassung erlegt irgendjemandem die Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine Person, die eine an sie delegierte oder ihr zugewiesene Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch darf sie nicht diesen Vorschriften oder Entscheidungen, die nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv entgegenwirken. - -# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann. - -# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt. - -1~ Einzelne Entwickler - -2~ Befugnisse - -Ein einzelner Entwickler darf - -# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen; - -# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten; - -# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen; - -# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen. - -2~ Zusammensetzung und Ernennung - -# Entwickler sind Freiwillige, die sich darin einig sind, die Ziele des Projekts insofern zu fördern, als sie an ihm teilhaben, und die ein oder mehrere Pakete für das Projekt betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten. - -# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2. - -2~ Verfahren - -Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten. - -1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl - -2~ Befugnisse - -Zusammen können die Entwickler - -# Den Projektleiter ernennen oder abberufen. - -# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu. - -# Jede vom Projektleiter oder einem Delegierten getroffene Entscheidung außer Kraft setzen. - -# Jede vom Technischen Ausschuss getroffene Entscheidung außer Kraft setzen, vorausgesetzt, sie stimmen dem mit einer 2:1-Mehrheit zu. - -# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen. - -Diese beinhalten Dokumente, welche die Ziele des Projekts und seine Beziehung zu anderen Gebilden der Freien Software beschreiben, sowie nicht-technische Richtlinien wie die Lizenzbedingungen für Freie Software, die Debian-Software erfüllen muss. - -Sie können auch Positionserklärungen zu Tagesfragen hinzufügen. - -_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden. - -_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software. - -_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen. - -# Zusammen mit dem Projektleiter und SPI Entscheidungen über mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum treffen. (Siehe §9.1.) - -2~ Verfahren - -# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird. - -# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten: - -_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3). - -_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies). - -_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können. - -_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, bis die vollständige Abstimmung über die Entscheidung durchgeführt wurde, oder ob die Erfüllung der ursprünglichen Entscheidung bis dahin verzögert wird. Es gibt bei dieser unmittelbaren verfahrensbezogenen Abstimmung kein Quorum. - -_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt. - -# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. - -# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q. - -# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben. - -# Stimmen werden in einer für den Schriftführer geeigneten Weise durch E-Mail abgegeben. Der Schriftführer legt für jede Abstimmung fest, ob die Abstimmenden ihre Stimme ändern können. - -# Q ist die Hälfte der Quadratwurzel aus der Anzahl der gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches davon kleiner ist. Q und K brauchen nicht ganze Zahlen sein und werden nicht gerundet. - -1~ Projektleiter - -2~ Befugnisse - -Der Projektleiter darf - -# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren. - -Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben. - -Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen. - -# Anderen Entwicklern Vollmacht erteilen. - -Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen. - -# Jede Entscheidung treffen, welche dringende Handlung erfordert. - -Dies gilt nicht für Entscheidungen, die nur durch einen Mangel an entsprechenden Maßnahmen allmählich dringend geworden sind, außer wenn es einen festen Stichtag gibt. - -# Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt. - -# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen. - -# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.) - -# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen. - -Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen. - -# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben). - -# Diskussionen unter Entwicklern leiten. - -Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern. - -# Zusammen mit SPI Entscheidungen treffen, die mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum betreffen. (Siehe §9.1.) - -2~ Ernennung - -# Der Projektleiter wird von den Entwicklern gewählt. - -# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort. - -# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren. - -# Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne nutzen (um ihre Person und Positionen bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt. - -# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist. - -# Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich »Niemand von den Obigen«. Falls »Niemand von den Obigen« die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig. - -# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist »Niemand von den Obigen«. - -# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang. - -2~ Verfahren - -Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind. - -Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen. - -Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft. - -1~ Technischer Ausschuss - -2~ Befugnisse - -Der Technische Ausschuss darf - -# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft. - -Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).) - -# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen. - -In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden. - -# Eine Entscheidung treffen, wenn er darum gebeten wird. - -Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen. - -# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit). - -Der Technische Ausschuss kann einen Entwickler darum bitten, einen bestimmten technischen Handlungsweg zu beschreiten, sogar wenn der Entwickler dies nicht wünscht; dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der Ausschuss festlegen, dass eine Beanstandung, die vom Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt werden sollte. - -# Rat anbieten. - -Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben. - -# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.) - -# Den Vorsitzenden des Technischen Ausschusses ernennen. - -Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern gewählt. Alle Mitglieder des Ausschusses werden automatisch nominiert; der Ausschuss beginnt eine Woche vor dem Freiwerden des Amtes zu wählen (oder sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt. - -# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten. - -Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt. - -2~ Zusammensetzung - -# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben. - -# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht. - -# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht. - -# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung. - -# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen. - -2~ Verfahren - -# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens. - -Ein Beschlussentwurf oder eine Abänderung kann von jedem Mitglied des Technischen Ausschusses vorgeschlagen werden. Es gibt keine Mindestfrist für Diskussionen; die Abstimmungsfrist dauert bis zu einer Woche, oder bis über den Ausgang kein Zweifel mehr besteht. Mitglieder können ihre Stimmen ändern. Das Quorum beträgt 2. - -# Einzelheiten, die die Abstimmung betreffen. - -Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der Technische Ausschuss darüber abstimmt, ob ein Entwickler, der ebenfalls Mitglied des Ausschusses ist, überstimmt werden soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er ist der Vorsitzende – in diesem Fall kann er nur seine ausschlaggebende Stimme benutzen). - -# Öffentliche Diskussion und Entscheidungsfindung. - -Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss. - -# Vertraulichkeit der Ernennungen. - -Der Technische Ausschuss kann vertrauliche Diskussionen durch private E-Mail, eine private Mailingliste oder andere Mittel abhalten, um Ernennungen in den Ausschuss zu diskutieren. Jedoch müssen Abstimmungen über Ernennungen öffentlich sein. - -# Keine Entwurfsarbeit in Einzelheiten. - -Der Technische Ausschuss nimmt nicht am Entwurf neuer Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit sollte von Einzelpersonen für sich oder zusammen durchgeführt werden und in gewöhnlichen Foren für technische Richtlinien und Entwürfe diskutiert werden. - -Der Technische Ausschuss beschränkt sich darauf, Kompromisse zwischen Lösungen und Entscheidungen, welche anderswo vorgeschlagen und hinreichend gründlich diskutiert worden sind, auszuwählen oder aufzunehmen. - -Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben. - -# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg. - -Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden und fehlgeschlagen sind, außer wenn er von der Person oder dem Organ, das normalerweise dafür verantwortlich ist, darum gebeten wurde, eine Entscheidung zu treffen. - -1~ Der Projekt-Schriftführer - -2~ Befugnisse - -Der Schriftführer - -# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert. - -# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten. - -Wenn es keinen Projektleiter gibt, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer in gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie dies als unumgänglich betrachten. - -# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft. - -# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen. - -2~ Ernennung - -Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt. - -Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie den Vorstand von SPI (siehe §9.1.) darum bitten, einen Schriftführer zu ernennen. - -Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des Technischen Ausschusses als stellvertretender Schriftführer die Entscheidung treffen oder delegieren. - -Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss. - -2~ Verfahren - -Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind. - -Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind. - -1~ Die Delegierten des Projektleiters - -2~ Befugnisse - -Die Delegierten des Projektleiters - -# haben vom Projektleiter an sie delegierte Befugnisse; - -# dürfen gewisse Entscheidungen treffen, die der Leiter nicht auf direkte Weise treffen darf. Dazu gehört, Entwickler anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu bestimmen, die keine Pakete betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern. - -2~ Ernennung - -Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter kann weder die Position des Delegierten von bestimmten Entscheidungen des Delegierten abhängig machen, noch kann er sich über eine Entscheidung hinwegsetzen, die einmal von einem Delegierten getroffen wurde. - -2~ Verfahren - -Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen. - -1~ Software in the Public Interest (»Software im öffentlichen Interesse«) - -SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet. Die Entwickler von Debian sind gegenwärtig Mitglieder von SPI auf Grund ihres Status als Entwickler. - -2~ Befugnis - -# SPI hat keine Befugnis, die Debians technische oder nicht-technische Entscheidungen betrifft, mit den Ausnahmen, dass keine Entscheidung durch Debian in Hinsicht auf irgendwelches von SPI verwaltetes Eigentum erfordern darf, dass SPI außerhalb seiner rechtlichen Befugnis handelt, und dass Debians Verfassung SPI gelegentlich als entscheidendes Organ letzter Instanz verwenden darf. - -# Debian beansprucht keine Befugnis über SPI außer der über die Verwendung gewissen Eigentums von SPI, wie weiter unten beschrieben wird. Dennoch können den Debian-Entwicklern innerhalb von SPI nach den Vorschriften von SPI Befugnisse erteilt werden. - -# Debian-Entwickler sind keine Vertreter oder Angestellte von SPI oder voneinander oder von innerhalb des Debian-Projekts mit Befugnis versehenen Personen. Eine Person, die als Entwickler handelt, tut dies als Einzelperson, im eigenen Namen. - -2~ Verwaltung von Eigentum für Zwecke, die mit Debian in Beziehung stehen - -Da Debian keine Befugnis hat, Geld oder Eigentum zu besitzen, müssen jegliche Spenden für das Debian-Projekt an SPI gemacht werden, das solche Angelegenheiten handhabt. - -SPI hat folgende Zusicherungen gemacht: - -# SPI besitzt für mit Debian in Beziehung stehende Zwecke Geld, Warenzeichen und anderes materielle und immaterielle Eigentum und handhabt andere Angelegenheiten. - -# Solches Eigentum wird für diese Zwecke, über die Debian und SPI entsprechend dieses Abschnitts entscheiden, treuhänderisch mit separater Rechenschaft verwaltet. - -# SPI wird kein für Debian treuhänderisch verwaltetes Eigentum veräußern oder verwenden, ohne dass eine Genehmigung durch Debian vorliegt. Diese kann vom Projektleiter oder durch Allgemeine Beschlüsse der Entwickler erteilt werden. - -# SPI wird in Betracht ziehen, treuhänderisch verwaltetes Eigentum zu verwenden oder zu veräußern, wenn es durch den Projektleiter darum gebeten wird. - -# SPI wird für Debian treuhänderisch verwaltetes Eigentum verwenden oder veräußern, wenn es durch einen Allgemeinen Beschluss der Entwickler darum gebeten wird, vorausgesetzt, dass dies mit der rechtlichen Befugnis von SPI verträglich ist. - -# SPI wird die Entwickler durch E-Mail auf einer Mailingliste des Debian-Projekts benachrichtigen, wenn es für Debian treuhänderisch verwaltetes Eigentum verwendet oder veräußert. - -1~a A. Standard-Beschlussverfahren - -Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben. - -2~a1 A.1. Beantragung - -Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf. - -2~a1a A.1. Diskussion und Abänderung - -# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses. - -# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht. - -# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses nicht mit der Annahme durch den Antragsteller einer formellen Abänderung einverstanden ist, bleibt die Abänderung eine Abänderung und es wird über sie abgestimmt. - -# Wenn eine vom ursprünglichen Antragsteller angenommene Abänderung nicht nach dem Geschmack Anderer ist, können diese eine weitere Abänderung einbringen, um die frühere Veränderung umzukehren (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein). - -# Der Antragsteller eines Beschlusses kann Veränderungen an der Formulierung von Abänderungen vorschlagen; diese werden wirksam, wenn der Antragsteller der Abänderung damit einverstanden ist und keiner der Befürworter dagegen ist. In diesem Fall wird anstelle der ursprünglichen über die veränderten Abänderungen abgestimmt. - -# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende Fehler (zum Beispiel Schreibfehler oder Ungereimtheiten) zu berichtigen, oder Veränderungen vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand erhebt innerhalb von 24 Stunden Einwände. In diesem Fall beginnt die Mindestfrist für Diskussionen nicht von vorn. - -2~a2 A.2. Aufruf zur Abstimmung - -# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist. - -# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen. - -# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter Abänderungen sind, und folglich, welche Form der Stimmzettel annehmen sollte. Dennoch liegt die endgültige Entscheidung über die Form des/der Stimmzettel beim Schriftführer – siehe §§7.1(1), 7.1(3) und A.3(4). - -# Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt, zu dem die letzte formelle Abänderung angenommen wurde, oder ab dem Zeitpunkt, zu dem der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden. - -2~a3 A.3. Wahlverfahren - -# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält. - -# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit. - -# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt »Weitere Diskussion«, wenn nicht eine andere bestimmt wurde. - -# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens. - -2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen - -Der Antragsteller eines Beschlusses oder einer nicht angenommenen Abänderung kann diese zurückziehen. In diesem Fall können neue Antragsteller hervortreten, um sie am Leben zu halten; dann wiederum wird die erste Person, die dies tut, der neue Antragsteller, und alle anderen werden Befürworter, wenn sie dies nicht bereits sind. - -Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen. - -Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt. - -2~a5 A.5. Verfall - -Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder auf andere Weise behandelt wurde, kann der Schriftführer eine Erklärung abgeben, dass man dabei ist, die Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der Anträge innerhalb einer Woche Einwände erhebt, wird die Angelegenheit zurückgezogen. - -Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll. - -2~a6 A.6. Stimmenzählung - -# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den »Aufruf zur Abstimmung« aufgenommen. - -# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen. - -# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen. - -_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen. - -_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist. - -_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1. - -# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen. - -_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist. - -# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen. - -_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt. - -# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen. - -_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt. - -# Wenn es Besiegungen zwischen Wahlmöglichkeiten gibt, die in der Schwartzschen Menge liegen, so lassen wir die schwächste solcher Besiegungen aus der Liste der paarweisen Besiegungen fallen und kehren zu Schritt 5 zurück. - -_# Eine Besiegung (A,X) ist schwächer als eine Besiegung (B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist (A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist, und V(X,A) größer als V(Y,B) ist. - -_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben. - -# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt. - -Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden. - -Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind. - -1~b B. Sprachgebrauch und Typographie - -Der Präsens Indikativ (zum Beispiel »ist«) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung ist. »Darf« oder »kann« zeigt an, dass es im Ermessen der Person oder des Organs liegt. »Sollte« bedeutet, dass es als gute Sache betrachtet würde, wenn der Satz befolgt würde, aber er ist nicht bindend. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen. - -Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~es.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~es.sst deleted file mode 100644 index 94f6325d..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~es.sst +++ /dev/null @@ -1,518 +0,0 @@ -% SiSU 0.38 - -@title: Constitución de Debian - -@subtitle: Constitución del Proyecto Debian (v1.2) [This Document has been Superseded by v1.3] - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2006-11-14 - -% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC - -@date: 2003-10-29 - -@language.document: Spanish - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.es.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.
Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ).
"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2~es.s3,v 1.6 2006/02/28 12:11:55 ralph Exp $ - -:A~ Constitución de Debian - -:B~ Constitución del Proyecto Debian (v1.2) [This Document has been Superseded by v1.3] - -1~pre [Prefix]-# - -Versión 1.2 ratificada el 29 de octubre de 2003. Sustituye a la versión 1.1 ratificada el 21 de junio de 2003, que a su vez sustituía a la versión 1.0 ratificada el 2 de diciembre de 1998. - -1~ 1. Introducción - -El Proyecto Debian es una asociación de individuos que han hecho causa común para crear un sistema operativo libre. - -Este documento describe la estructura organizativa para la toma de decisiones en el Proyecto. No describe las metas del Proyecto o cómo alcanzarlas, ni contiene ninguna norma excepto aquellas relacionadas directamente con el proceso de toma de decisiones. - -1~ 2. Individuos y organismos de toma de decisiones - -Cada decisión en el Proyecto la toman uno o más de los siguientes: - -# Los Desarrolladores, mediante una Resolución General o una elección; - -# El Líder del Proyecto; - -# El Comité Técnico o su Presidente (chairman); - -# El Desarrollador que trabaja en una tarea determinada; - -# Delegados nombrados por el Líder del Proyecto para tareas específicas; - -# El Secretario del Proyecto. - -La mayoría del resto de este documento le ayudará a formar una idea de las atribuciones de estos organismos, su composición y nombramientos, y el proceso de toma de decisiones. Las atribuciones de una persona u organismo pueden estar sujetos a revisión y/o limitación por parte de terceros; en ese caso el organismo o personas encargadas de la revisión indicarán dicha posibilidad. En la lista anterior, normalmente se lista a una persona u organismo antes de aquellos cuyas decisiones puede anular o a los que escoge (o ayuda a escoger); pero no todos los que se nombran al principio mandan sobre todos los posteriores. - -2~ Reglas generales - -# Nada en esta constitución impone obligaciones a nadie que trabaje para el Proyecto. Una persona que no quiera hacer la tarea que le ha sido delegada o asignada no necesita hacerla. Sin embargo, no se debe actuar activamente en contra de estas reglas y las decisiones tomadas apropiadamente siguiéndolas. - -# Una persona puede ocupar varios puestos, pero el Líder del Proyecto, el Secretario del Proyecto y el Presidente del Comité Técnico deben ser personas distintas, además de que el Líder no puede elegirlos como sus Delegados. - -# Una persona puede abandonar el Proyecto o dimitir de un cargo en particular, en cualquier momento, diciéndolo públicamente. - -1~ Desarrolladores individuales - -2~ Atribuciones - -Un Desarrollador puede - -# tomar una decisión técnica o no técnica con respecto a su propio trabajo; - -# proponer o patrocinar borradores de Resoluciones Generales; - -# proponerse a sí mismos como candidatos a Líder del Proyecto durante las elecciones; - -# votar en una Resolución General y en las elecciones a Líder. - -2~ Composición y nombramiento - -# Los Desarrolladores son voluntarios que colaboran para hacer avanzar los objetivos del proyecto mientras participan en él, y que mantienen paquetes para el Proyecto, o realizan alguna otra tarea que el (los) Delegado(s) del Líder del Proyecto consideren adecuada. - -# El (o los) Delegado(s) del Líder del Proyecto puede(n) elegir no admitir nuevos Desarrolladores, o expulsar a los que ya lo sean. Si los Desarrolladores consideran que los Delegados están abusando de su autoridad pueden por supuesto anular su decisión mediante la vía de una Resolución General (vea §4.1(3), §4.2). - -2~ Procedimiento - -Los Desarrolladores pueden tomar estas decisiones según crean adecuado. - -1~ Los Desarrolladores mediante una Resolución General o elección - -2~ Atribuciones - -En conjunto, los Desarrolladores pueden: - -# Elegir o cesar al Líder del Proyecto. - -# Enmendar esta constitución, siempre que esté de acuerdo con una mayoría de las tres cuartas partes. - -# Anular cualquier decisión del Líder del Proyecto o uno de sus Delegados. - -# Anular cualquier decisión del Comité Técnico, siempre y cuándo estén de acuerdo dos terceras partes. - -# Generar documentos no técnicos sobre normas y declaraciones. - -Generar, sustituir y retirar documentos sobre normas y declaraciones no técnicos. -# - -Esto incluye documentos que describan los objetivos del proyecto, sus relaciones con otras entidades de software libre, y normas no técnicas tales como los términos de licencias de software libre a los que debe ajustarse el software de Debian. - -También pueden formular recomendaciones sobre los asuntos incluidos en el orden del día. - -_# Un Documento Fundamental (Foundation Document) es un documento o declaración clasificada como crítica para la misión y propósitos del Proyecto. - -_# Los Documentos Fundamentales son las obras tituladas Contrato Social de Debian (Debian Social Contract) y Directrices de Software libre de Debian (Debian Free Software Guidelines). - -_# La sustitución de un Documento Fundamental precisa de una mayoría de las tres cuartas partes. Se pueden generar nuevos Documentos Fundamentales y retirar los ya existentes mediante una enmienda a la lista de Documentos Fundamentales en esta constitución. - -# Junto con el Líder del Proyecto y SPI, tomar decisiones sobre las propiedades mantenidas en fideicomiso para propósitos relacionados con Debian (Ver §9.1.) - -2~ Procedimiento - -# Los Desarrolladores seguirán el Procedimiento Estándar de Resolución, que se indica más adelante. Se introduce una resolución o enmienda si algún desarrollador la propone y es apoyado por al menos otros 'K' Desarrolladores, o si es propuesta por el Líder del Proyecto o el Comité Técnico. - -# Retraso de una decisión del Líder del Proyecto o sus Delegados: - -_# Si el Líder del Proyecto o sus Delegados, o el Comité Técnico han tomado una decisión, los Desarrolladores pueden invalidarla aprobando una resolución que lo haga; vea s4.1(3). - -_# Si tal resolución es apoyada por al menos '2K' Desarrolladores, o si es propuesta por el Comité Técnico, provoca que la decisión sea congelada de forma inmediata (siempre que la propia resolución lo indique). - -_# Si la decisión original versaba sobre cambiar el periodo de un debate o votación, o si la resolución pretende anular uan decisión del Comité Técnico, entonces sólo hace falta el apoyo de 'K' Desarrolladores para poder congelar inmediatamente la decisión. - -_# Si la decisión queda postergada, se votará inmediatamente para determinar si se mantiene la decisión hasta que se produzca una votación formal al respecto, o si se deberá retrasar la implementación de la decisión original hasta entonces. No hay quorum para esta votación inmediata. - -_# Si el Líder del Proyecto (o su Delegado) se retracta de la decisión original, la votación se hace innecesaria, y no se lleva a cabo. - -# El Secretario del Proyecto toma los votos. Los votos y resultados del recuento no son revelados durante el periodo de votación; una vez terminado, el Secretario del Proyecto publicará todos los votos depositados. El periodo de votación es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana. - -# El periodo mínimo de discusión es de dos semanas, pero el Líder del Proyecto puede variarlo en hasta una semana. El Líder tiene un voto decisivo. El quorum es de 3Q. - -# Las propuestas, patrocinadores, enmiendas, llamadas a votación y otras acciones formales se anuncian en una lista de correo electrónico pública señalada por el (los) Delegado(s) del Líder del Proyecto. Cualquier desarrollador podrá enviar mensajes a ella. - -# Los votos son depositados mediante correo electrónico de una manera que el Secretario considere adecuada. El Secretario determinará, para cada votación, si los votantes pueden cambiar su voto. - -# Q es la mitad de la raíz cuadrada del número total de Desarrolladores. K es Q o 5, lo que sea más pequeño. Q y K no tienen por qué ser enteros, y no se les aplica redondeo. - -1~ El Líder del Proyecto - -2~ Poderes - -El Líder del Proyecto puede: - -# Nombrar Delegados o delegar decisiones en el Comité Técnico. - -El Líder puede definir un área de responsabilidad o una decisión específica y delegarla en otro Desarrollador o en el Comité Técnico. - -Una vez que una decisión en particular se haya delegado y se haya tomado, el Líder del Proyecto no puede retirar esa delegación; sin embargo, puede retirar una delegación actual de un área de responsabilidad en particular. - -# Ceder autoridad a otros Desarrolladores. - -El Líder del Proyecto puede respaldar a otros miembros del proyecto o sus opiniones, tanto si se le solicita como por propia voluntad. Sin embargo, sus declaraciones tendrán «fuerza» si y sólo si se le ha dado potestad para tomar la decisión en cuestión. - -# Tomar cualquier decisión que precise una acción urgente. - -Esto no se aplica a decisiones que se hayan vuelto urgentes de forma gradual debido a la falta de acción relevante, a menos que haya un plazo fijado. - -# Tomar cualquier decisión sobre la que ningún otro tenga responsabilidad. - -# Proponer borradores de Resoluciones Generales y enmiendas. - -# Junto al Comité Técnico, nombrar nuevos miembros del Comité. (Ver §6.2.) - -# Usar su voto decisivo cuando los Desarrolladores votan. - -El Líder también dispone de un voto normal en tales votaciones. - -# Variar el periodo de discusión de las votaciones de los desarrolladores (tal como se dijo anteriormente). - -# Dirigir discusiones entre Desarrolladores. - -El Líder debería intentar participar en las discusiones entre Desarrolladores de una manera útil, intentando mantener la discusión dentro de los temas clave. El Líder del Proyecto no debería usar su posición para promocionar sus opiniones personales. - -# Junto con SPI, tomar decisiones que afecten a propiedad cedida en préstamo para propósitos relacionados con Debian. (Ver §9.1.) - -2~ Nombramiento - -# El Líder del Proyecto es elegido por los Desarrolladores. - -# La elección comienza nueve semanas antes de que el puesto quede vacante, o (si ya es demasiado tarde) inmediatamente. - -# Durante las tres semanas siguientes cualquier Desarrollador puede proponerse a sí mismo como candidato a Líder del Proyecto. - -# Durante las siguientes tres semanas, no se podrán proponer más candidatos; los que ya lo sean deberían usar este tiempo para hacer campaña (hacer conocer sus identidades y sus opiniones). Si no hay candidatos al final del periodo de nominación, queda extendido por otras tres semanas, repetidamente si fuera necesario. - -# Las tres semanas siguientes constituyen el tiempo de votación, durante el cual los Desarrolladores pueden emitir su voto. Los votos destinados a la elección de un líder se mantendrán en secreto, incluso tras acabar el periodo de elecciones. - -# Las opciones que aparezcan en la papeleta serán las de aquellos candidatos que se hayan propuesto a sí mismos, y no se hayan retirado, además de "None Of The Above" (Ninguno de los anteriores). Si None Of The Above gana las elecciones, entonces se ha de repetir el proceso, tantas veces como sea necesario. - -# La decisión se tomará usando el método especificado en la sección §A.6 del Procedimiento Estándar de Resolución. El quórum es el mismo que para una Resolución General (§4.2) y la opción por defecto es "None Of The Above". - -# El Líder del Proyecto ejerce un año de mandato tras su elección. - -2~ Procedimiento - -El Líder del Proyecto debería intentar tomar decisiones consistentes con el consenso de las opiniones de los Desarrolladores. - -Cuando sea práctico, el Líder debería solicitar informalmente la opinión de los Desarrolladores - -El Líder debería evitar presentar sus propios puntos de vista con demasiado énfasis cuando tome decisiones en su calidad de Líder. - -1~ Comité técnico - -2~ Poderes - -El Comité Técnico puede: - -# Decidir sobre cualquier norma en materia técnica - -Esto incluye el contenido de los manuales de normativa técnica (policy), material de referencia para desarrolladores, paquetes de ejemplo y el comportamiento de herramientas para construcción de paquetes que no sean experimentales. En cada caso, el mantenedor original del software o documentación relevante toma las decisiones iniciales, sin embargo (Ver § 6.3(5)). - -# Decidir sobre cualquier materia técnica donde se solape la jurisdicción de los Desarrolladores. - -En los casos en que varios Desarrolladores necesiten implementar normas técnicas compatibles (por ejemplo, si no están de acuerdo en las prioridades de paquetes en conflicto, o sobre la propiedad del nombre de una orden, o sobre qué paquete es responsable de un fallo cuando ambos mantenedores están de acuerdo en que es un fallo, o sobre quién debería mantener un paquete), el comité técnico puede decidir sobre el asunto. - -# Tomar una decisión cuando se le pida. - -Cualquier persona u organismo puede delegar una decisión en el Comité Técnico, o pedirle consejo. - -# Imponer su decisión sobre la de un Desarrollador (precisa una mayoría de las tres cuartas partes). - -El Comité Técnico puede indicar a un Desarrollador que siga un curso de acción técnico en particular, incluso si no es el que desea; esto precisa una mayoría de las tres cuartas partes. Por ejemplo, el Comité puede determinar que está justificada una queja formulada por quien envía un informe de bug, y que debe implementarse la solución que propuso. - -# Ofrecer consejo. - -El Comité Técnico puede hacer anuncios formales sobre su punto de vista en cualquier asunto. Los miembros individuales pueden, por supuesto, hacer propuestas informales sobre sus puntos de vista y sobre los del comité. - -# Junto con el Líder del Proyecto, nombrar nuevos miembros para sí mismo, o eliminar a los existentes. (Ver §6.2.) - -# Nombrar al Presidente del Comité Técnico. - -Al Presidente lo elige el Comité de entre sus miembros. Todos los miembros del comité quedan nominados automáticamente; la votación comienza una semana antes de que el puesto quede vacante (o inmediatamente, si ya es demasiado tarde). Los miembros pueden votar por aclamación pública a cualquier colega miembro del comité, incluyéndose a sí mismos; no existe la opción predeterminada. La votación termina cuando todos los miembros hayan emitido su voto, o cuando haya terminado el periodo de votación. El resultado se determina usando el método especificado en la sección A.6 del Procedimiento Estándar de Resolución. - -# El Presidente puede ejercer las funciones de Líder, junto con el Secretario. - -Como se detalla en la §7.1(2), el Presidente del Comité Técnico y el Secretario del Proyecto pueden, en conjunto, ejercer las funciones del Líder si no hay Líder. - -2~ Composición - -# El Comité Técnico se compone de hasta 8 Desarrolladores, y normalmente debería tener al menos 4 miembros. - -# Cuando hayan menos de 8 miembros, el Comité Técnico puede recomendar nuevos miembros al Líder del Proyecto, quien puede escoger (individualmente) si nombrarlos o no. - -# Cuando haya 5 miembros o menos, el Comité Técnico puede nombrar nuevos miembros hasta que su número total llegue a 6. - -# Cuando el número de miembros sea de 5 o menos durante al menos una semana, el Líder del Proyecto podrá nombrar nuevos miembros hasta que su número llegue a 6, a intervalos de al menos una semana por nombramiento. - -# Si el Comité Técnico y el Líder del Proyecto están de acuerdo, pueden destituir o sustituir a un miembro del Comité Técnico. - -2~ Procedimiento - -# El Comité Técnico usa el Procedimiento Estándar de Resolución. - -Cualquier miembro del Comité Técnico puede proponer un borrador de resolución o enmienda. No hay periodo mínimo de discusión; el periodo de votación dura una semana, o hasta que el resultado esté fuera de duda. Los miembros pueden cambiar sus votos. Existe un quorum de dos. - -# Detalles al respecto de la votación - -El Presidente dispone de un voto decisivo. Cuando el Comité Técnico vota si se debe anular la autoridad de un Desarrollador que además es miembro del Comité, ese miembro no podrá votar (a menos que sea el Presidente, en cuyo caso sólo podrá usar su voto decisivo). - -# Discusión pública y toma de decisiones. - -Las discusiones, borradores de resoluciones y enmiendas, y votaciones de los miembros del comité, se hacen públicas en la lista pública de discusión del Comité Técnico. El Comité no dispone de secretario propio. - -# Confidencialidad de los acuerdos. - -El Comité Técnico puede mantener discusiones confidenciales mediante mensajes electrónicos privados, una lista de correo privada, o cualquier otro medio para discutir acuerdos del Comité. Sin embargo, las votaciones sobre dichos acuerdos deben ser públicas. - -# Trabajo de diseño poco detallado. - -El Comité Técnico no se encarga del diseño de nuevas propuestas y normas. Tal trabajo de diseño debe ser llevado acabo por individuos de forma privada o conjunta y discutida en los foros ordinarios dedicados al diseño y normativa técnicos. - -El Comité Técnico se restringe a sí mismo a adoptar o escoger compromisos entre soluciones y decisiones que hayan sido propuestas y razonablemente discutidas en otro lugar. - -Los miembros individuales del comité pueden, por supuesto, participar a título personal en cualquier aspecto del trabajo en diseño y normativa. - -# El Comité Técnico toma decisiones sólo como último recurso. - -El Comité Técnico no toma decisiones técnicas hasta que hayan fracasado otros esfuerzos para resolverlo por la vía del consenso, a menos que así se lo pida la persona u organismo responsables de dicha decisión. - -1~ El Secretario del Proyecto - -2~ Poderes - -El Secretario: - -# Recibe los votos de los Desarrolladores, y determina el número e identidad de los Desarrolladores, siempre que la constitución lo requiera. - -# Puede ejercer las funciones de Líder, junto con el Presidente del Comité Técnico. - -Si no hay Líder del Proyecto, entonces el Presidente del Comité Técnico y el Secretario del Proyecto pueden tomar decisiones mediante acuerdo si consideran imperativo hacerlo. - -# Juzga cualquier disputa sobre interpretaciones de la constitución. - -# Puede delegar parte de su autoridad en cualquier otro, o derogar tal delegación en cualquier momento. - -2~ Nombramiento - -El nuevo Secretario del Proyecto es nombrado por el Líder del Proyecto y por el Secretario que abandona el cargo. - -Si el Líder del Proyecto y el Secretario saliente no llegan a un acuerdo sobre el nuevo nombramiento, deberán pedir al Consejo de SPI (ver §9.1.) el nombramiento de un Secretario. - -Si no hay Secretario del Proyecto o el Secretario actual no está disponible, y no ha delegado la autoridad para una decisión, entonces el Presidente del Comité Técnico puede tomar tal decisión o delegarla, como Secretario en funciones. - -El ejercicio del Secretario del Proyecto dura 1 año, en cuyo momento debe escogerse otro Secretario o ratificarle en el cargo. - -2~ Procedimiento - -El Secretario del Proyecto debería tomar decisiones que sean justas y razonables, preferiblemente consistentes con el consenso de los Desarrolladores. - -Cuando actúen juntos en función del Líder del Proyecto ausente, el Presidente del Comité Técnico y el Secretario del Proyecto deberían tomar decisiones sólo cuando fuera absolutamente necesario y sólo siendo consistentes con el consenso de los Desarrolladores. - -1~ Los Delegados del Líder del Proyecto - -2~ Poderes - -Los Delegados del Líder del Proyecto: - -# disponen de los poderes que el Líder del Proyecto haya delegado en ellos; - -# pueden tomar ciertas decisiones que el Líder no puede tomar directamente, incluyendo la admisión o expulsión de Desarrolladores o nombramiento de personas como Desarrolladores que no mantienen paquetes. Esto evita la concentración de poder, particularmente sobre la pertenencia al proyecto de un Desarrollador, en manos del Líder del Proyecto. - -2~ Nombramiento - -Los Delegados son nombrados por el Líder del Proyecto y pueden ser reemplazados a discreción del Líder. El Líder no puede condicionar el puesto de Delegado sobre decisiones particulares que éste tome, ni puede anular una decisión del Delegado, una vez tomada. - -2~ Procedimiento - -Los Delegados toman las decisiones que crean convenientes, pero debertían intentar implementarlas de una forma técnicamente correcta o siguiente una opinión de consenso. - -1~ Software in the Public Interest - -SPI y Debian son organizaciones separadas que comparten algunos objetivos. Debian agradece la estructura de soporte legal que le ofrece SPI. Los Desarrolladores de Debian son actualemente miembros de SPI por virtud de su estatus de Desarrollador. - -2~ Autoridad - -# SPI carece de poder de decisión sobre cuestiones técnicas y de cualquier otro ámbito relacionadas con Debian, con la salvedad de que Debian no podrá imponerse a SPI en ningún caso que contravenga a su autoridad legal sobre las propiedades en poder de SPI, si bien la constitución de Debian podrá recurrir a SPI como órgano decisorio en última instancia - -# Debian no pretende autoridad alguna sobre SPI otra que el uso de ciertos bienes de SPI, tal como se describe más adelante, aunque se pueda conceder autoridad dentro de SPI a los Desarrolladores de Debian mediante las propias reglas de SPI. - -# Los Desarrolladores de Debian no son agentes comerciales ni empleados de SPI, ni unos de otros, ni de personas con autoridad en el Proyecto Debian. Una persona actuando como Desarrollador lo hace como individuo, en su propio nombre. - -2~ Gestión de bienes para propósitos relacionados con Debian - -Dado que Debian no puede poseer dinero ni bienes, cualquier donación al Proyecto Debian debe ser dirigida a SPI, que gestiona tales cuestiones. - -SPI garantiza lo siguiente: - -# SPI actuará como depositario del dinero, marcas registradas y otros bienes tangibles e intangibles y gestionará otros asuntos con propósitos relacionados con Debian. - -# Tales bienes serán contabilizados por separado y mantenidos en fideicomiso para dichos propósitos, decididos por Debian y SPI de acuerdo a esta sección. - -# SPI no dispondrá de o usará bienes mantenidos en fideicomiso para Debian sin la aprobación de Debian, que debe ser emitida por el Líder del Proyecto o mediante una Resolución General de los Desarrolladores. - -# SPI tomará en consideración usar o disponer de bienes mantenidos en fideicomiso para Debian cuando se lo pida el Líder del Proyecto. - -# SPI usará o dispondrá de bienes mantenidos en fideicomiso para Debian cuando le sea pedido mediante una Resolución General de los Desarrolladores, siempre que sea compatible con la autoridad legal de SPI. - -# SPI informará a los Desarrolladores mediante mensaje electrónico a una lista del Proyecto Debian cuando use o disponga de bienes mantenidos en fideicomiso para Debian. - -1~a A. Procedimiento Estándar de Resolución - -Estas reglas se aplican a la toma de decisiones comunitaria de comités y plebiscitos, tal como se indicó anteriormente. - -2~a1 A.1. Propuesta - -El procedimiento formal comienza cuando se propone y patrocina un borrador de resolución, tal como se requiere. - -2~a1a A.1. Discusión y Enmienda - -# Siguiendo la propuesta, se debe discutir la resolución. Se pueden hacer enmiendas formales proponiéndolas y patrocinándolas de acuerdo a los requerimientos de una nueva resolución, o haciéndolo directamente el proponente de la resolución original. - -# El proponente de la resolución puede aceptar una enmienda formal, en cuyo caso se cambia inmediatamente el borrador de la resolución formal para que se ajuste a la enmienda. - -# Si no se acepta una enmienda formal, o uno de los patrocinadores de la resolución no está de acuerdo con que el proponente acepte la enmienda formal, se mantiene como enmienda y pasa a ser votada. - -# Si una enmienda aceptada por el proponente original no es del gusto de otros, pueden proponer otra enmienda para invertir el cambio anterior (de nuevo, necesitan cumplir los requerimientos de proponente y patrocinador(es).) - -# El proponente o una resolución pueden sugerir cambios en el texto de la enmienda; lo cual tendrá efecto si el proponente de la enmienda está de acuerdo y ninguno de sus patrocinadores se opone. En tal caso se votará la enmienda modificada en lugar de la original. - -# El proponente de una resolución puede hacer cambios para corregir errores menores (por ejemplo, errores tipográficos o inconsistencias) o cambios que no alteren el significador, siempre que nadie objete en las siguientes 24 horas. En este caso, no se reinicia el periodo mínimo de discusión. - -2~a2 A.2. Llamada a urnas - -# El proponente o patrocinador de una moción o enmienda puede pedir una votación, siempre que haya pasado el tiempo mínimo de discusión (si es que lo había). - -# El proponente o patrocinador de una moción puede pedir una votación sobre esa resolución y todas las enmiendas relacionadas. - -# La persona que pide una votación indica el que cree que debería ser el texto de la resolución y cualquier enmienda relevante y, consecuentemente, el contenido de las papeletas. Sin embargo, la decisión final del contenido de las papeletas es del Secretario (Ver 7.1(1), 7.1(3) y A.3(4)) - -# El periodo mínimo de discusión se cuenta desde el momento en que fue aceptada la última enmienda formal, o el momento en que se propuso la resolución si no se han propuesto y aceptado enmiendas. - -2~a3 A.3. Procedimiento de votación - -# Cada resolución y sus enmiendas relacionadas se votan en una única papeleta que incluye una opción para la resolución original, cada enmienda, y la opción predeterminada (si se aplica). - -# La opción predeterminada no tiene ningún requerimiento de supermayoría. Las opciones que no precisen explícitamente de supermayoría, tienen un requerimiento de mayoría 1:1. - -# Los votos se cuentan de acuerdo con las reglas en A.6. La opción predeterminada es "Further Discussion", a menos que se especifique otra cosa. - -# En caso de duda, el Secretario del Proyecto decidirá en materia de procedimiento. - -2~a4 A.4. Retirada de resoluciones o enmiendas rechazadas - -El proponente de una resolución o enmienda rechazada puede retirarla. En este caso, pueden aparecer nuevos proponentes para mantenerlas activas, en cuyo caso la primera persona que lo haga se convierte en el nuevo proponente y cualquier otro se convierte en patrocinador si no los había ya. - -El patrocinador de una resolución o enmienda puede retirarse (a menos que sea aceptada). - -Si la retirada del proponente o patrocinadores implica que la resolución no tiene proponente o suficientes patrocinadores, no será llevada a votación a menos que se rectifique antes de que la resolución expire. - -2~a5 A.5. Expiración - -Si una resolución propuesta no ha sido discutida, enmendada, votada o movida de alguna manera durante 4 semanas el secretario puede anunciar que está siendo retirada. Si ninguno de los patrocinadores de cualquiera de las propuestas objeta durante una semana, la resolución se retira. - -El secretario también puede incluir sugerencias sobre cómo proceder, si fuera apropiado. - -2~a6 A.6. Recuento de votos - -# La papeleta de cada votante califica las opciones sobre las que se vota. No hace falta calificar todas las opciones. Las opciones calificadas se consideran preferidas sobre todas las que no lo hayan sido. Los votantes pueden dar la misma calificación a las opciones. Se considera que las no calificadas tienen la misma calificación entre ellas. Se incluirán en la Llamada al voto los detalles de la manera en que se debe rellenar la papeleta. - -# Si la papeleta precisa un quórum R, cualquier opción diferente a la predeterminada que no obtenga al menos R votos calificándola por encima de la opción predeterminada se elimina de toda consideración. - -# Cualquier opción (que no sea la predeterminada) que no venza a la predeterminada por la proporción de mayoría precisada se elimina de toda consideración. - -_# Dadas dos opciones A y B, V(A,B) es el número de votantes que prefieren la opción A sobre la opción B. - -_# Una opción A vence a la opción predeterminada D por una proporción de mayoría N, si V(A, D) es estrictamente mayor que N * V(D,A). - -_# Si A necesita una supermayoría de S:1, su proporción de mayoría es S; si no, su proporción de mayoría es 1. - -# De la lista de opciones sin eliminar, generamos una lista de derrotas a pares. - -_# Una opción A vence a una opción B, si V(A,B) es estrictamente mayor que V(B,A). - -# De una lista de derrotas a pares (sin eliminar), generamos un conjunto de derrotas transitivas. - -_# Una opción A derrota transitivamente a una opción C si A derrota a C o si hay otra opción B donde A derrota a B Y B derrota transitivamente a C. - -# Construimos el conjunto de Schwartz partiendo del conjunto de derrotas transitivas. - -_# Una opción A está en el conjunto de Schwartz si para todas las opciones B, bien A derrota transitivamente a B, o B no derrota transitivamente a A. - -# Si hay derrotas entre opciones en el conjunto de Schwartz, eliminamos a la más débil de tales derrotas de la lista de derrotas por pares, y volvemos al quinto paso. - -_# Una derrota (A,X) es más débil que una derrota (B,Y) si V(A,X) es menor que V(B,Y). Además, (A,X) es más débil que (B,Y) si V(A,X) es igual a V(B,Y) y V(X,A) es mayor que V(Y,B). - -_# La derrota más débil es aquella que no tiene ninguna derrota más débil que ella. Puede haber más de una de tales derrotas. - -# Si no hay derrotas dentro del conjunto de Schwartz, entonces el ganador se escoge de entre las opciones en dicho conjunto. Si sólo hay una de tales opciones, es la ganadora. Si hay varias, el elector con el voto de calidad escoge cual de estas opciones gana. - -Nota: Las opciones que los votantes califiquen por encima de la opción predeterminada son aquellas que encuentran aceptables. Las opciones calificadas por debajo de la predeterminada son las que encuentran inaceptables. - -Cuando se deba usar el Procedimiento Estándar de Resolución, el texto que se refiera a ello debe especificar si es suficiente tener un borrador o patrocinadores de la resolución propuesta, cual es el periodo mínimo de discusión, y el periodo de votación. También se debe especificar la necesidad de una mayoría absoluta o el quorum (y la opción por defecto) necesario. - -1~b B. Uso del lenguaje y tipografía - -N. del T.: se refiere al original en ingles. - -EL presente indicativo (`is', por ejemplo) indica que la frase es una regla de esta constitución. `May' o `can' indica que la persona u organismo puede actuar a discreción. `Should' indica que se consideraría bien la obediencia a dicha frase, pero no es vinculante. El texto marcado como cita, tal como éste, indica la base lógica del texto, y no forma parte de la constitución. Se debe usar sólo como ayuda en caso de duda. - -% Volver a la página principal de Debian. -% Cómo modificar el idioma por defecto de los documentos -% Para informar de un problema con el servidor web, por favor, envíe un correo (en inglés) a debian-www@lists.debian.org. Para consultar información de contacto adicional consulte la página de contactos de Debian. -% Última modificación: mar, 14 de nov de 2006, 15:44:29 UTC -% Proyecto Debian -% Elija un servidor cerca de usted -% Nota: La página original es más nueva que esta traducción. -% Constitución de Debian -% Constitución del Proyecto Debian (v1.2) - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~fr.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~fr.sst deleted file mode 100644 index c15899d8..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~fr.sst +++ /dev/null @@ -1,509 +0,0 @@ -% SiSU 0.38 - -% Dernière modification : jeudi 2 novembre 2006 06:33:05 UTC -% Copyright © 1997-2006 SPI; voir les termes de la licence. -% Debian est une marque déposée de Software in the Public Interest, Inc. -% Note : le document original est plus récent que cette traduction. -% Constitution Debian -% Constitution du Projet Debian (v1.2) - -@title: Constitution Debian - -@subtitle: Constitution du Projet Debian (v1.2) [This Document has been Superseded by v1.3] - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2006-11-02 - -@date: 2003-10-29 - -@language.document: French - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Ce matériel ne peut être distribué que conformément aux termes et conditions présentés dans la Licence de Publication Ouverte (Open Publication License), Draft v.1.0 ou suivantes. (Vous pouvez lire notre copie locale http://www.debian.org/opl, dont la version la plus récente est généralement disponible à http://www.opencontent.org/ ).
« Debian » et le logo Debian sont des marques déposées appartenant à Software in the Public Interest, Inc.
En cas de litige, seule la version originale de cette page a valeur au regard de la loi http://www.debian.org/license.en.html. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2~fr.s3,v 1.6 2006/02/28 12:11:55 ralph Exp $ - -:A~ Constitution Debian - -:B~ Constitution du Projet Debian (v1.2) [This Document has been Superseded by v1.3] - -1~pre [Prefix]-# - -Version 1.2 ratifiée le 29 octobre 2003. Remplace la Version 1.1 ratifiée le 21 juin 2003, qui elle même remplace la Version 1.0 ratifiée le 2 décembre 1998. - -1~ Introduction - -Le Projet Debian est une association d'individus qui ont pris pour cause commune la création d'un système d'exploitation libre. - -Ce document décrit la structure organisationnelle pour les prises de décisions formelles dans le Projet. Il ne décrit pas les buts du Projet ni comment il les atteint, ni ne contient aucune règle excepté celles directement relatives au processus de prise de décision. - -1~ Corps et individus prenant les décisions - -Chaque décision dans le Projet est faite par un ou plus des suivants : - -# Les Développeurs, par Résolution Générale ou par vote ; - -# Le Chef du Projet ; - -# Le Comité Technique et/ou son Président ; - -# Le Développeur individuel travaillant sur une certaine tâche ; - -# Des Délégués nommés par le Chef du Projet pour des tâches spécifiques ; - -# Le Secrétaire du Projet. - -La plus grosse partie du reste de ce document esquissera les pouvoirs de ces corps, leur composition et leur nomination, et les procédures de leurs prises de décisions. Les pouvoirs d'une personne ou d'un corps peuvent être sujet à révision et/ou limitation par d'autres; dans ce cas le passage concernant le corps ou la personne pouvant faire la révision l'indiquera. Dans la liste ci dessus, une personne ou un corps est habituellement cité avant les personnes ou les corps dont ils peuvent outrepasser les décisions ou qu'ils nomment (ou aident à nommer) - mais ceux qui sont cités avant ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités ensuite. - -2~ Règles Générales - -# Rien dans cette constitution n'impose à quiconque d'obligation de faire un travail pour le Projet. Une personne qui ne veut pas faire une tâche qui lui a été déléguée ou assignée n'a pas à la faire. Cependant, elle ne doit pas travailler activement contre ces règles et les décisions prises convenablement qui en découlent. - -# Une personne peut cumuler plusieurs postes, excepté le fait que le Chef du Projet, le Secrétaire du Projet et le Président du Comité Technique doivent être distincts, et que le Chef ne peut pas les nommer pour être leurs propres Délégués. - -# Une personne peut quitter le Projet ou démissionner d'un poste particulier qu'elle tient, à n'importe quel moment, en le disant publiquement. - -1~ Les Développeurs Individuels - -2~ Pouvoirs - -Un Développeur individuel peut - -# prendre n'importe quelle décision technique ou non technique en rapport avec son propre travail ; - -# proposer ou soutenir des projets de Résolutions Générales ; - -# se proposer lui même comme candidat pour les élections au poste de Chef du Projet ; - -# voter les Résolutions Générales et lors des élections au poste de Chef du Projet. - -2~ Composition et nomination - -# Les développeurs sont des volontaires qui s'accordent à poursuivre les buts du Projet en ce qu'ils y participent, et qui maintiennent des paquets pour le Projet ou font tout autre travail que les Délégués du Chef du Projet considèrent utile. - -# Les Délégués du Chef du Projet peuvent choisir de ne pas admettre de nouveaux Développeurs, ou d'expulser des Développeurs existant. Si les Développeurs pensent que les Délégués abusent de leur autorité ils peuvent bien sûr outrepasser la décision par Résolution Générale - voir §4.1(3), §4.2. - -2~ Procédure - -Les Développeurs peuvent prendre ces décisions comme ils le souhaitent. - -1~ Les Développeurs par Résolution Générale ou élection - -2~ Pouvoirs - -Ensemble, les Développeurs peuvent : - -# Nommer ou rétrograder le Chef du Projet. - -# Amender cette constitution, pourvu qu'ils soient d'accord avec une majorité de 3 contre 1. - -# Outrepasser n'importe quelle décision du Chef du Projet ou d'un Délégué. - -# Outrepasser n'importe quelle décision du Comité Technique, pourvu qu'ils soient d'accord avec une majorité de 2 contre 1. - -# Produire, mettre à jour ou retirer des déclarations ou des documents régulateurs non techniques. - -Ceci inclut des documents décrivant les buts du projet, ses relations avec d'autres entités du logiciel libre, et des règles non techniques comme les termes de la licence de logiciel libre que les logiciels Debian doivent satisfaire. - -Cela peut aussi inclure des déclarations de position concernant les problèmes du jour. - -_# Un document fondateur (« Foundation Document ») est un document ou une déclaration considéré comme critique pour la mission ou les objectifs du Projet. - -_# Les documents fondateurs sont les travaux appelés Contrat social Debian (« Debian Social Contract ») et Directives Debian pour le logiciel libre (« Debian Free Software Guidelines »). - -_# Il est nécessaire d'avoir une majorité de 3:1 pour mettre à jour un document fondateur. Les nouveaux documents fondateurs sont produits et les documents fondateurs existants sont retirés, en amendant la liste des documents fondateurs dans cette constitution. - -# Ensemble avec le Chef du Projet et SPI, prendre des décisions à propos des biens mis en commun pour les besoins de Debian. (Voir §9.1.) - -2~ Procédure - -# Les Développeurs suivent la Procédure Standard de Résolution, ci dessous. Une résolution ou un amendement est introduit si il est proposé par n'importe quel Développeur et soutenu par au moins K autres Développeurs, ou si il est proposé par le Chef du Projet ou le Comité Technique. - -# Retarder une décision du Chef du Projet ou d'un Délégué : - -_# Si le Chef du Projet ou son Délégué, ou le Comité Technique, a pris une décision, alors les Développeurs peuvent l'outrepasser en adoptant une résolution pour cela ; voir s4.1(3). - -_# Si une telle résolution est soutenue par au moins 2K Développeurs, ou si elle est proposée par le Comité Technique, la résolution suspend la décision immédiatement (pourvu que la résolution elle même le demande). - -_# Si la décision originale était de changer la période de discussion ou de vote, ou si la résolution est d'outrepasser le Comité Technique, alors seulement K Développeurs doivent soutenir la résolution pour pouvoir suspendre immédiatement la décision. - -_# Si la décision est suspendue, un vote immédiat est tenu pour déterminer si la décision sera applicable jusqu'à ce que le vote complet sur la décision soit fait ou si l'implémentation de la décision originale sera retardée jusqu'à ce moment. Il n'y a pas de quorum pour ce vote procédural immédiat. - -_# Si le Chef du Projet (ou le Délégué) retire la décision originale, le vote devient inutile, et n'est plus poursuivi. - -# Les votes sont reçus par le Secrétaire du Projet. Les votes, les contrôles et les résultats ne doivent pas être révélés pendant la durée du scrutin ; après le scrutin, le Secrétaire du Projet liste tous les contenus des votes. La durée du scrutin est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet. - -# La période de discussion minimum est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet. Le Chef du Projet a un vote discriminant. Il y a un quorum de 3Q. - -# Les propositions, soutiens, amendements, appels au vote et autres actions formelles sont faites par annonces sur une liste de discussion électronique à lecture publique désignée par le Délégué du Chef du Projet; n'importe quel Développeur peut poster sur celle-ci. - -# Les votes sont envoyés par courrier électronique d'une façon qui convienne au Secrétaire. Le Secrétaire détermine pour chaque scrutin si les votants peuvent changer leurs votes. - -# Q est la moitié de la racine carré du nombre de Développeurs courant. K est le minimum de Q et de 5. Q et K ne sont pas forcément entiers et ne sont pas arrondis. - -1~ Le Chef du Projet - -2~ Pouvoirs - -Le Chef du Projet peut : - -# Nommer des Délégués ou déléguer des décisions au Comité Technique. - -Le Chef peut définir un domaine de responsabilité ou une décision courante spécifique et la confier à un autre Développeur ou au Comité Technique. - -Une fois qu'une décision particulière a été déléguée et faite, le Chef du Projet ne peut retirer cette délégation ; cependant, il peut retirer une délégation courante d'une aire de responsabilité particulière. - -# Prêter de l'autorité à d'autres Développeurs. - -Le Chef de Projet peut faire des déclarations de soutien à des points de vue ou à d'autres membres du projet, que cela lui soit demandé ou non ; ces déclarations ont du poids si et seulement si le Chef a le pouvoir de prendre la décision en question. - -# Prendre n'importe quelle décision qui demande une action urgente. - -Cela ne s'applique pas aux décisions qui sont seulement devenues graduellement urgente à cause d'un manque d'action significative, sauf s'il y a une date butoir. - -# Prendre n'importe quelle décision pour laquelle personne d'autre n'a de responsabilité. - -# Proposer des Résolutions Générales et des amendements. - -# Ensemble avec le Comité Technique, nommer de nouveaux membres au Comité. (Voir §6.2.) - -# Utiliser un vote discriminant quand les Développeurs votent. - -Le Chef de Projet a aussi un vote normal dans ces scrutins. - -# Changer la période de discussion des vote des Développeurs (comme ci-dessus). - -# Mener les discussions parmi les Développeurs. - -Le Chef de Projet devrait essayer de participer aux discussions parmi les Développeurs d'une manière utile qui cherche à amener la discussion à traiter des problèmes clés en suspend. Le Chef de Projet ne devrait pas utiliser sa position d'autorité pour promouvoir ses vues personnelles. - -# Ensemble avec SPI, prendre les décisions affectant les biens possédés en commun pour les besoins relatifs à Debian. (Voir §9.1.) - -2~ Nomination - -# Le Chef de Projet est élu par les Développeurs. - -# Une élection commence neuf semaines avant que le poste de chef ne devienne vacant, ou (si c'est déjà trop tard) immédiatement. - -# Pendant les trois semaines suivantes n'importe quel Développeur peut se porter candidat au poste de Chef du Projet. - -# Pendant les trois semaines suivantes, aucun candidat ne peut plus se présenter ; les candidats devraient utiliser cette période pour faire campagne (pour faire connaître leurs identités et leurs positions). S'il n'y a pas de candidats à la fin de la période de désignation alors cette période est étendue de trois semaines supplémentaires, répétitivement si nécessaire. - -# Les trois semaines suivantes sont la période de scrutin pendant laquelle les Développeurs peuvent envoyer leurs votes. Les votes de l'élection du chef sont tenus secrets, même après que l'élection est finie. - -# Les choix possibles sur les bulletins seront les candidats qui se sont désignés et qui ne se sont pas encore retirés, plus le choix « None Of The Above » (Aucun de ceux qui précèdent). Si le choix « None Of The Above » gagne l'élection alors la procédure d'élection est recommencée, plusieurs fois si nécessaire. - -# La décision sera prise en utilisant la méthode spécifiée dans la section §A.6 de la Procédure de Résolution Standard. Le quorum est le même que pour une Résolution Générale (§4.2) et l'option par défaut est « None Of The Above ». - -# Le Chef du Projet est désigné pour une année à compter de son élection. - -2~ Procédure - -Le Chef du Projet devrait essayer de prendre des décisions qui sont consistantes avec le consensus d'opinions des Développeurs. - -Lorsque c'est possible le Chef du Projet devrait solliciter de manière informelle les opinions des Développeurs. - -Le Chef du Projet devrait éviter de trop souligner son propre point de vue quand il s'agit de prendre des décisions qui relèvent de ses attributions de Chef. - -1~ Comité Technique - -2~ Pouvoirs - -Le Comité Technique peut : - -# Décider sur n'importe quel sujet concernant les règles techniques. - -Cela inclut le contenu des manuels de règles techniques, des documents de référence pour les développeurs, des paquets exemples et le comportement des outils non expérimentaux de création de paquets (dans chaque cas, le responsable du logiciel concerné ou de la documentation prend les décisions initialement, cependant ; voir 6.3(5)). - -# Décider sur n'importe quel sujet technique où les juridictions des Développeurs se recouvrent. - -Dans les cas où les Développeurs ont besoin d'implémenter des règles techniques compatibles ou des décisions (par exemple, s'ils ne sont pas d'accord sur les priorités de paquets en conflit, ou pour attribuer la propriété d'un nom de commande, ou pour déterminer quel paquet est responsable d'un bogue que les deux responsables reconnaissent être un bogue, ou pour désigner le responsable d'un paquet), le Comité Technique peut décider sur le sujet. - -# Prendre une décision quand on le lui demande. - -Une personne ou un corps peut déléguer une décision de son ressort au Comité Technique, ou chercher conseil auprès de lui. - -# Outrepasser un Développeur (demande une majorité de 3 contre 1). - -Le Comité Technique peut demander à un Développeur de choisir une solution technique particulière même si le Développeur ne le souhaite pas ; cela demande une majorité de 3 contre 1. Par exemple, le Comité peut décider qu'une complainte faite par une personne soumettant un bogue est justifiée et que la solution proposée par celui qui soumet le bogue devrait être implémentée. - -# Offrir conseil. - -Le Comité Technique peut faire des annonces formelles à propos de ses vues sur n'importe quel sujet. Les membres individuels peuvent bien sûr faire des déclarations informelles à propos de leurs vues et à propos des vues probables du comité. - -# Ensemble avec le Chef du Projet, nommer de nouveaux membres en son sein ou en retirer. (Voir §6.2.) - -# Nommer le Président du Comité Technique. - -Le Président est élu par le Comité à partir de ses membres. Tous les membres du Comité sont automatiquement nommés ; le Comité vote en commençant une semaine avant que le poste ne devienne vacant (ou immédiatement, si c'est déjà trop tard). Les membres peuvent voter par acclamation publique pour n'importe quel membre du Comité, y compris eux-même ; il n'y a pas de choix par défaut. Le vote se termine lorsque tous les membres ont voté ou quand la période du scrutin se termine. Le résultat est déterminé en utilisant la méthode décrite dans la section A.6 de la Procédure standard de résolution. - -# Le Président peut représenter le Chef, ensemble avec le Secrétaire. - -Comme détaillé dans §7.1(2), le Président du Comité Technique et le Secrétaire du Projet peuvent ensemble représenter le Chef s'il n'y a pas de Chef. - -2~ Composition - -# Le Comité Technique est constitué d'au plus 8 Développeurs, et devrait normalement avoir au moins 4 membres. - -# Quand il y a moins de 8 membres le Comité Technique peut recommander un nouveau membre (ou plus) au Chef du Projet, qui peut choisir (individuellement) de les nommer ou pas. - -# Quand il y a 5 membres ou moins, le Comité Technique peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6. - -# Quand il y a eu 5 membres ou moins pendant au moins une semaine, le Chef du Projet peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6, à intervalles d'au moins une semaine par nomination. - -# Si le Comité Technique et le Chef du Projet sont d'accord ils peuvent retirer ou remplacer un membre existant du Comité Technique. - -2~ Procédure - -# Le Comité Technique utilise la Procédure Standard de Résolution. - -Une proposition de résolution ou un amendement peut être proposé par n'importe quel membre du Comité Technique. Il n'y a pas de période de discussion minimum ; la période de vote dure jusqu'à une semaine, ou jusqu'à ce que le résultat ne fasse plus de doute. Les membres peuvent modifier leurs votes. Il y a un quorum de deux. - -# Détails concernant le vote. - -Le Président a une voix discriminante. Lorsque le Comité Technique vote pour outrepasser un Développeur qui est aussi un membre du Comité, ce membre ne peut pas voter (sauf s'il s'agit du Président, auquel cas il peut utiliser seulement sa voix discriminante). - -# Discussion publique et prise de décision. - -Les discussions, propositions de résolutions et amendements, et votes par les membres du Comité, sont rendus publics sur la liste de discussion du Comité Technique. Il n'y a pas de secrétariat séparé pour le Comité. - -# Confidentialité des nominations. - -Le Comité Technique peut rendre confidentielles les discussions par courrier électronique privé ou par liste de diffusion privée ou d'autres moyens afin de discuter les nominations au Comité. Cependant, les votes des nominations doivent être publics. - -# Pas de travail de conception détaillé. - -Le Comité Technique ne s'engage pas dans la conception de nouvelles propositions et de nouvelles règles. Ce travail de conception doit être mené par les individus de manière privée ou ensemble et discuté dans des forums techniques ordinaires de conception et de choix d'implémentation. - -Le Comité Technique se restreint à choisir ou adopter des compromis entre les solutions et décisions qui ont été proposées et suffisamment bien discutées ailleurs. - -Les membres individuels du Comité Technique peuvent bien sûr participer en leur propre nom à tous les aspects du travail de conception et de choix d'implémentation. - -# Le Comité Technique prend les décisions uniquement en dernier ressort. - -Le Comité Technique ne prend pas de décision technique tant que des efforts de résolution par consensus n'ont pas été menés et n'ont pas échoué sauf s'il lui a été demandé de prendre la décision par la personne ou le corps qui en serait normalement responsable. - -1~ Le Secrétaire du Projet - -2~ Pouvoirs - -Le Secrétaire : - -# Reçoit les votes des Développeurs, et détermine le nombre et l'identité des Développeurs, quand c'est requis par la constitution. - -# Peut représenter le Chef, avec le Président du Comité Technique. - -S'il n'y a pas de Chef du Projet alors le Président du Comité Technique et le Secrétaire du Projet peuvent par accord mutuel prendre des décisions s'ils considèrent comme impératif de le faire. - -# Résout les divergences d'interprétation de la constitution. - -# Peut déléguer une part ou toute son autorité à quelqu'un d'autre, ou retirer une telle délégation à tout moment. - -2~ Nomination - -Le Secrétaire du Projet est nommé par le Chef du Projet et le Secrétaire du Projet courant. - -Si le Chef du Projet et le Secrétaire du Projet courant ne peuvent se mettre d'accord sur une nouvelle nomination, ils doivent demander au conseil d'administration de SPI (voir §9.1.) de nommer un Secrétaire. - -S'il n'y a pas de Secrétaire du Projet ou si le Secrétaire courant n'est pas disponible et n'a pas délégué d'autorité pour une décision alors la décision peut être faite ou déléguée par le Président du Comité Technique, en tant que Secrétaire en Acte. - -La durée du mandat de Secrétaire du Projet est de un an, à la suite duquel lui ou un autre Secrétaire doit être (re)nommé. - -2~ Procédure - -Le Secrétaire du Projet devrait prendre des décisions justes et raisonnables, et de préférence en accord avec le consensus des Développeurs. - -Quand ils agissent ensemble pour représenter un Chef du Projet absent, le Président du Comité Technique et le Secrétaire du Projet devraient prendre des décisions seulement quand c'est absolument nécessaire et seulement en accord avec le consensus des Développeurs. - -1~ Les Délégués du Chef du Projet - -2~ Pouvoirs - -Les Délégués du Chef du Projet : - -# ont les pouvoirs qui leurs sont délégués par le Chef du Projet ; - -# peuvent prendre certaines décisions que le Chef ne peut prendre directement, y compris approuver ou expulser des Développeurs ou désigner des gens comme Développeurs qui ne maintiennent pas de paquets. C'est pour éviter la concentration des pouvoirs, particulièrement au sujet de la qualité de Développeur, dans les mains du Chef du Projet. - -2~ Nomination - -Les Délégués sont nommés par le Chef du Projet et peuvent être remplacés par le Chef à sa discrétion. Le Chef du Projet ne peut rendre le poste de Délégué conditionnel à des décisions particulières du Délégué, ni outrepasser une décision prise par un Délégué une fois prise. - -2~ Procédure - -Les Délégués peuvent prendre les décisions selon leur convenance, mais devraient essayer d'implémenter de bonnes décisions techniques et/ou suivre l'opinion consensuelle. - -1~ Software in the Public Interest - -SPI et Debian sont des organisations séparées qui partagent certains buts. Debian remercie SPI pour le support légal offert par cette organisation.Les Développeurs Debian sont des membres courants de SPI de par leur status de Développeurs. - -2~ Autorité - -# SPI n'a pas d'autorité concernant les décisions techniques ou non techniques de Debian, excepté que toute décision de Debian concernant tous les biens gardés par SPI nécessite que SPI agisse en dehors de son autorité légale, et que la constitution de Debian peut occasionnellement utiliser SPI comme un corps de décision en dernier ressort. - -# Debian ne revendique aucune autorité sur SPI autre que l'utilisation de certains biens de SPI, comme décrit ci dessous, bien que les Développeurs Debian peuvent recevoir des responsabilité à l'intérieur de SPI suivant les règles de SPI. - -# Les Développeurs Debian ne sont pas des agents ou des employés ni de SPI, ni les uns des autres, ni de personnes ayant des responsabilités dans le Projet Debian. Une personne agissant en tant que Développeur le fait en tant qu'individu, de son propre chef. - -2~ Gestion des biens pour les besoins de Debian - -Comme Debian n'a pas d'autorité légale pour garder de l'argent ou des biens, tous les dons pour le Projet Debian doivent être faits à SPI, qui gère ce type d'affaires. - -SPI a pris les engagements suivants : - -# SPI gardera l'argent, les marques commerciales et les autres biens tangibles et intangibles et gérera des affaires pour les besoins de Debian ; - -# Ces biens seront comptabilisés séparément et gardés en commun pour ces besoins, les décisions les concernant seront prises par Debian et SPI conformément à cette section ; - -# SPI n'utilisera pas et ne disposera pas de ces biens gardés en commun pour Debian sans l'approbation de Debian, qui peut être fournie par le Chef du Projet ou par Résolution Générale des Développeurs ; - -# SPI pourra utiliser et disposer de ces biens gardés en commun pour Debian quand cela lui sera demandé par le Chef du Projet ; - -# SPI utilisera et disposera de ces biens gardés en commun pour Debian quand cela lui sera demandé par Résolution Générale des Développeurs, pourvu que cela soit compatible avec l'autorité légale de SPI ; - -# SPI informera les Développeurs par courrier électronique sur la liste de diffusion du Projet Debian quand il utilisera ou disposera des biens gardés en commun pour Debian. - -1~a A. Procédure de Résolution Standard - -Ces règles s'appliquent aux prises de décision communes par comités et plébiscites, là où cela est indiqué plus haut. - -2~a1a A.1. Proposition - -La procédure formelle commence quand un projet de résolution est proposé et soutenu, comme il est requis. - -2~a1a A.1. Discussion et Amendements - -# Après la proposition, la résolution peut être discutée. Les amendements peuvent être rendus formels en étant proposés et soutenus conformément aux exigences d'une nouvelle résolution, ou directement par celui qui a proposé la résolution originale. - -# Un amendement formel peut être accepté par celui qui propose la résolution, dans ce cas la proposition de résolution formelle est immédiatement modifiée pour s'y accorder. - -# Si un amendement formel n'est pas accepté, ou si l'un de ceux qui soutiennent la résolution n'est pas d'accord avec l'acceptation d'un amendement formel par celui qui propose la résolution, l'amendement reste un amendement et sera mis au vote. - -# Si un amendement accepté par celui qui a originellement proposé la résolution n'est pas du goût d'autres développeurs, ils peuvent proposer un autre amendement pour inverser les changements précédents (de même, ils doivent satisfaire aux exigences relatives à celui qui le propose et ceux qui le soutiennent). - -# Celui qui propose la résolution ou la résolution elle-même peuvent suggérer des modifications à la rédaction des amendements ; ils prennent effet si celui qui propose un amendement est d'accord et si aucun de ceux qui le soutiennent ne s'y oppose. Dans ce cas les amendements modifiés seront votés à la place des amendements originaux. - -# Celui qui propose une résolution peut faire des modifications pour corriger des erreurs mineures (par exemple, des erreurs typographiques ou des inconsistances) ou changements qui n'en modifient pas la signification, pourvu que personne ne s'y oppose dans les 24 heures. Dans ce cas la période de discussion minimum n'est pas recommencée. - -2~a2 A.2. Appel à voter - -# Celui qui propose ou l'un de ceux qui soutiennent une motion ou un amendement peuvent appeler à voter, pourvu que la période de discussion minimum (s'il y en a) soit terminée. - -# Celui qui propose ou l'un de ceux qui soutiennent une résolution peuvent appeler à voter sur cette résolution et tous les amendements liés. - -# La personne qui appelle à voter déclare ce qu'elle croît devoir être la formulation de la résolution et des amendements liés, et en conséquence ce que la forme du bulletin doit être. Cependant, la décision finale sur la forme du ou des bulletins est celle du Secrétaire - voir 7.1(1), 7.1(3) et A.3(4). - -# La période de discussion minimum est comptée à partir du moment où le dernier amendement formel a été accepté, ou à partir du moment où l'entière résolution a été proposée si aucun amendement n'a été proposé et accepté. - -2~a3 A.3. Procédure de vote - -# Chaque résolution et les amendements qui lui sont liés sont soumis aux votes en un seul scrutin qui contient une option pour la résolution originale, pour chaque amendement, et pour l'option par défaut (quand elle s'applique). - -# L'option par défaut ne doit nécessiter aucune supermajorité. Les options qui ne nécessitent pas de supermajorité ont besoin d'une majorité de 1:1 pour être adoptés. - -# Les votes sont comptabilisés suivant les règles de A.6. L'option par défaut est « Further Discussion » (Discussion prolongée), sauf en cas de spécification contraire. - -# En cas de doutes le Secrétaire du Projet devra décider sur les questions de procédure. - -2~a4 A.4. Retrait des résolutions et des amendements non encore acceptés - -Celui qui propose une résolution ou un amendement non encore accepté peut le retirer. Dans ce cas certains peuvent vouloir le (ou la) garder, auquel cas la première personne qui souhaite le (ou la) garder devient celui qui le (ou la) propose et les autres soutiennent alors si ce n'est pas déjà le cas. - -Ceux qui soutiennent une résolution ou un amendement (sauf s'il a été accepté) peuvent se retirer. - -Si le retrait de celui qui propose et/ou de ceux qui soutiennent implique qu'une résolution ou un amendement ne soit plus proposée ou n'ai pas assez de personne qui la soutienne elle ne sera pas voté sauf si cela est rectifié avant que la résolution expire. - -2~a5 A.5. Expiration - -Si une résolution proposée n'a pas été discutée, amendée, votée ou traitée d'une façon ou d'une autre pendant 4 semaines, le Secrétaire peut décréter que la résolution est retirée. Si aucun de ceux qui soutiennent l'une des propositions ne manifeste son désaccord pendant une semaine, la résolution est retirée. - -Le Secrétaire peut aussi suggérer des façons de procéder, si besoin. - -2~a6 A.6. Comptabilisation des Votes - -# Chaque bulletin de vote classe les options soumises au vote. Il n'est pas nécessaire que toutes les options apparaissent dans le classement. Les options apparaissant dans le classement sont considérées comme préférées à toutes celles qui n'y apparaissent pas. Les votants peuvent classer à égalité plusieurs options. Les options non classées sont considérées comme étant à égalité les unes avec les autres. Les détails sur la façon dont les bulletins doivent être remplis seront contenus dans l'appel à voter. - -# Si le scrutin nécessite un quorum R, toute option autre que celle par défaut, qui ne reçoit pas au moins R votes qui la classent au dessus de l'option par défaut, est ignorée. - -# Toute option (autre que celle par défaut), qui ne bat pas l'option par défaut avec un rapport au moins égal à celui de la majorité requise, est ignorée. - -_# Étant donné deux options A et B, V(A,B) est le nombre de votants préférant l'option A à l'option B. - -_# Une option A bat l'option par défaut D avec un rapport de majorité N, si V(A,D) est strictement supérieur à N * V(D,A). - -_# Si une supermajorité de S:1 est nécessaire pour A, son rapport de majorité est S; sinon, il est égal à 1. - -# À partir de la liste des options non ignorées, nous générons une liste des vainqueurs deux à deux. - -_# Une option A bat une option B, si V(A,B) est strictement supérieur à V(B,A). - -# À partir de la liste des vainqueurs [non-ignorés] deux à deux, nous générons un ensemble des vainqueurs transitifs. - -_# Une option A bat transitivement une option C si A bat C ou s'il y a une autre option B telle que A bat B ET B bat transitivement C. - -# Nous construisons l'ensemble de Schwartz à partir de l'ensemble des vainqueurs transitif. - -_# Une option A est dans l'ensemble de Schwartz si pour toutes les options B, soit A bat transitivement B, soit B ne bat pas transitivement A. - -# S'il y a des options qui en battent d'autres dans l'ensemble de Schwartz, nous sortons les plus faibles des vainqueurs de la liste des vainqueurs deux à deux, et retournons à l'étape 5. - -_# Une victoire (A,X) est plus faible qu'une victoire (B,Y) si V(A,X) est inférieur à V(B,Y). Et de plus, (A,X) est plus faible que (B,Y) si V(A,X) est égal à V(B,Y) et V(X,A) est plus grand que V(Y,B). - -_# Une plus faible victoire est une victoire qui n'a pas de victoire plus faible qu'elle. Il peut y avoir plusieurs victoires de ce type. - -# S'il n'y a pas de plus faible dans l'ensemble de Schwartz set, alors le vainqueur est choisi dans l'ensemble de Schwartz set. S'il n'y a qu'une seule option, c'est le vainqueur. S'il y en a plusieurs, le votant ayant un vote discriminant choisi l'option qui gagne parmi celles-ci. - -Note : Les options que les votants classent au dessus de l'option par défaut sont celles qu'ils trouvent acceptables. Les options classées en dessous de l'option par défaut sont les options qu'ils trouvent inacceptables. - -Quand la Procédure de Résolution Standard est utilisée, le texte qui y fait référence doit spécifier ce qui est suffisant pour qu'une proposition de résolution soit proposée et/ou soutenue, ce qu'est la période de discussion minimum, et ce qu'est la période de vote. Il doit aussi spécifier quelle supermajorité et/ou le quorum (et le choix par défaut) à utiliser. - -1~b B. Utilisation du langage et typographie - -Le présent ou le futur de l'indicatif (« est » ou « sera », par exemple) signifie que l'affirmation est une règle dans cette constitution. Le verbe « Pouvoir » indique que la personne ou le corps a le choix. Le verbe « Devoir » au conditionnel indique que cela serait considéré comme une bonne chose si ce qui prescrit était respecté, mais cela n'est pas obligatoire. Le texte marqué comme une citation, comme celui ci, se veut simplement raisonnable et ne fait pas partie de la constitution. Il peut être utilisé seulement pour aider à l'interprétation en cas de doute. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.adjusted.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.adjusted.sst deleted file mode 100644 index db0776cd..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.adjusted.sst +++ /dev/null @@ -1,508 +0,0 @@ -% SiSU 0.38 - -% Last Modified: Tue, Nov 14 15:39:52 UTC 2006 -% Copyright © 1997-2006 SPI; See license terms -% Debian is a registered trademark of Software in the Public Interest, Inc. - -@title: Debian Constitution - -@subtitle: Constitution for the Debian Project (v1.3) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2006-09-24 - -@date.available: 2006-09-24 - -@date.modified: 2006-11-14 - -@date: 2006-09-24 - -@language.document: English - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{Debian Project}http://www.debian.org/ -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Site map}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.
Version 1.3 ratified on September 24th, 2006. Supersedes Version 1.2 ratified on October 29th, 2003 and Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.3.adjusted.sst,v 1.1 2006/11/23 01:36:16 ralph Exp ralph $ - -:A~ Debian Constitution - -:B~ Constitution for the Debian Project (v1.3) - -1~pre [Prefix]-# - -{Version 1.3}http://www.debian.org/devel/constitution.1.3 ratified on September 24th, 2006. Supersedes {Version 1.2}http://www.debian.org/devel/constitution.1.2 ratified on October 29th, 2003 and {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998. - -1~ 1. Introduction - -/{The Debian Project is an association of individuals who have made common cause to create a free operating system.}/ - -This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process. - -1~ 2. Decision-making bodies and individuals - -Each decision in the Project is made by one or more of the following: - -_1 1. The Developers, by way of General Resolution or an election; - -_1 2. The Project Leader; - -_1 3. The Technical Committee and/or its Chairman; - -_1 4. The individual Developer working on a particular task; - -_1 5. Delegates appointed by the Project Leader for specific tasks; - -_1 6. The Project Secretary. - -Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later. - -2~ 2.1. General rules - -_1 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. - -_1 2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. - -_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly. - -1~ 3. Individual Developers - -2~ 3.1. Powers - -An individual Developer may - -_1 1. make any technical or nontechnical decision with regard to their own work; - -_1 2. propose or sponsor draft General Resolutions; - -_1 3. propose themselves as a Project Leader candidate in elections; - -_1 4. vote on General Resolutions and in Leadership elections. - -2~ 3.2. Composition and appointment - -_1 1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile. - -_1 2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2. - -2~ 3.3. Procedure - -Developers may make these decisions as they see fit. - -1~ 4. The Developers by way of General Resolution or election - -2~ 4.1. Powers - -Together, the Developers may: - -_1 1. Appoint or recall the Project Leader. - -_1 2. Amend this constitution, provided they agree with a 3:1 majority. - -_1 3. Make or override any decision authorised by the powers of the Project Leader or a Delegate. - -_1 4. Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority. - -_1 5. Issue, supersede and withdraw nontechnical policy documents and statements. - -These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. - -They may also include position statements about issues of the day. - -_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes. - -_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines. - -_2 3. A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution. - -_1 6. Make decisions about property held in trust for purposes related to Debian. (See §9.). - -_1 7. In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary. - -2~ 4.2. Procedure - -_1 1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. - -_1 2. Delaying a decision by the Project Leader or their Delegate: - -_2 1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3). - -_2 2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). - -_2 3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. - -_2 4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. - -_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted. - -_1 3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. - -_1 4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. - -_1 5. Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there. - -_1 6. Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes. - -_1 7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded. - -1~ 5. Project Leader - -2~ 5.1. Powers - -The {Project Leader}http://www.debian.org/devel/leader may: - -_1 1. Appoint Delegates or delegate decisions to the Technical Committee. - -_1 The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. - -_1 Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility. - -_1 2. Lend authority to other Developers. - -_1 The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question. - -_1 3. Make any decision which requires urgent action. - -_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline. - -_1 4. Make any decision for whom noone else has responsibility. - -_1 5. Propose draft General Resolutions and amendments. - -_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) - -_1 7. Use a casting vote when Developers vote. - -_1 The Project Leader also has a normal vote in such ballots. - -_1 8. Vary the discussion period for Developers' votes (as above). - -_1 9. Lead discussions amongst Developers. - -_1 The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. - -_1 10. In consultation with the developers, make decisions affecting property held in trust for purposes related to Debian. (See §9.). Such decisions are communicated to the members by the Project Leader or their Delegate(s). Major expenditures should be proposed and debated on the mailing list before funds are disbursed. - -_1 11. Add or remove organizations from the list of trusted organizations (see §9.3) that are authorized to accept and hold assets for Debian. The evaluation and discussion leading up to such a decision occurs on an electronic mailing list designated by the Project Leader or their Delegate(s), on which any developer may post. There is a minimum discussion period of two weeks before an organization may be added to the list of trusted organizations. - -2~ 5.2. Appointment - -_1 1. The Project Leader is elected by the Developers. - -_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately. - -_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader. - -_1 4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary. - -_1 5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. - -_1 6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. - -_1 7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is "None Of The Above". - -_1 8. The Project Leader serves for one year from their election. - -2~ 5.3. Procedure - -The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. - -Where practical the Project Leader should informally solicit the views of the Developers. - -The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader. - -1~ 6. Technical committee - -2~ 6.1. Powers - -The {Technical Committee}http://www.debian.org/devel/tech-ctte may: - -_1 1. Decide on any matter of technical policy. - -_1 This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).) - -_1 2. Decide any technical matter where Developers' jurisdictions overlap. - -_1 In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter. - -_1 3. Make a decision when asked to do so. - -_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it. - -_1 4. Overrule a Developer (requires a 3:1 majority). - -_1 The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. - -_1 5. Offer advice. - -_1 The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee. - -_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.) - -_1 7. Appoint the Chairman of the Technical Committee. - -_1 The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. - -_1 8. The Chairman can stand in for the Leader, together with the Secretary - -_1 As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. - -2~ 6.2. Composition - -_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. - -_1 2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. - -_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. - -_1 4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. - -_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. - -2~ 6.3. Procedure - -_1 1. The Technical Committee uses the Standard Resolution Procedure. - -_1 A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. - -_1 2. Details regarding voting - -_1 The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote). - -_1 3. Public discussion and decision-making. - -_1 Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee. - -_1 4. Confidentiality of appointments. - -_1 The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public. - -_1 5. No detailed design work. - -_1 The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. - -_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. - -_1 Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work. - -_1 6. Technical Committee makes decisions only as last resort. - -_1 The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. - -1~ 7. The Project Secretary - -2~ 7.1. Powers - -The {Secretary:}http://www.debian.org/devel/secretary - -_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution. - -_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee. - -_1 If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. - -_1 3. Adjudicates any disputes about interpretation of the constitution. - -_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time. - -2~ 7.2. Appointment - -The Project Secretary is appointed by the Project Leader and the current Project Secretary. - -If the Project Leader and the current Project Secretary cannot agree on a new appointment, they must ask the Developers by way of General Resolution to appoint a Secretary. - -If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary. - -The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed. - -2~ 7.3. Procedure - -The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers. - -When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. - -1~ 8. The Project Leader's Delegates - -2~ 8.1. Powers - -The Project Leader's Delegates: - -_1 1. have powers delegated to them by the Project Leader; - -_1 2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. - -2~ 8.2. Appointment - -The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made. - -2~ 8.3. Procedure - -Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. - -1~ 9. Assets held in trust for Debian - -In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, property has to be owned by any of a number of organisations as detailed in §9.2. - -Traditionally, SPI was the sole organisation authorized to hold property and monies for the Debian Project. SPI was created in the U.S. to hold money in trust there. - -SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. - -2~ 9.1. Relationship with Associated Organizations - -_1 1. Debian Developers do not become agents or employees of organisations holding assets in trust for Debian, or of each other, or of persons in authority in the Debian Project, solely by the virtue of being Debian Developers. A person acting as a Developer does so as an individual, on their own behalf. Such organisations may, of their own accord, establish relationships with individuals who are also Debian developers. - -2~ 9.2. Authority - -_1 1. An organisation holding assets for Debian has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by the organisation shall require it to act outside its legal authority. - -_1 2. Debian claims no authority over an organisation that holds assets for Debian other than that over the use of property held in trust for Debian. - -2~ 9.3. Trusted organisations - -Any donations for the Debian Project must be made to any one of a set of organisations designated by the Project leader (or a delegate) to be authorized to handle assets to be used for the Debian Project. - -Organisations holding assets in trust for Debian should undertake reasonable obligations for the handling of such assets. - -Debian maintains a public List of Trusted Organisations that accept donations and hold assets in trust for Debian (including both tangible property and intellectual property) that includes the commitments those organisations have made as to how those assets will be handled. - -1~a A. Standard Resolution Procedure - -These rules apply to communal decision-making by committees and plebiscites, where stated above. - -2~a1 A.1. Proposal - -The formal procedure begins when a draft resolution is proposed and sponsored, as required. - -2~a1a A.1. Discussion and Amendment - -_1 1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. - -_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. - -_1 3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. - -_1 4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).) - -_1 5. The proposer or a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals. - -_1 6. The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted. - -2~a2 A.2. Calling for a vote - -_1 1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. - -_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. - -_1 3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). - -_1 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. - -2~a3 A.3. Voting procedure - -_1 1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). - -_1 2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. - -_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise. - -_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure. - -2~a4 A.4. Withdrawing resolutions or unaccepted amendments - -The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already. - -A sponsor of a resolution or amendment (unless it has been accepted) may withdraw. - -If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires. - -2~a5 A.5. Expiry - -If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. - -The secretary may also include suggestions on how to proceed, if appropriate. - -2~a6 A.6. Vote Counting - -_1 1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes. - -_1 2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. - -_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. - -_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. - -_2 2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). - -_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. - -_1 4. From the list of undropped options, we generate a list of pairwise defeats. - -_2 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A). - -_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats. - -_2 1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C. - -_1 6. We construct the Schwartz set from the set of transitive defeats. - -_2 1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A. - -_1 7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5. - -_2 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). - -_2 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat. - -_1 8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. - -!_ Note: -Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. - -/{ When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used. }/ - -2~b B. Use of language and typography - -The present indicative (`is', for example) means that the statement is a rule in this constitution. `May' or `can' indicates that the person or body has discretion. `Should' means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.sst deleted file mode 100644 index 2bec8440..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3.sst +++ /dev/null @@ -1,508 +0,0 @@ -% SiSU 0.38 - -% Last Modified: Tue, Nov 14 15:39:52 UTC 2006 -% Copyright © 1997-2006 SPI; See license terms -% Debian is a registered trademark of Software in the Public Interest, Inc. - -@title: Debian Constitution - -@subtitle: Constitution for the Debian Project (v1.3) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2006-09-24 - -@date.available: 2006-09-24 - -@date.modified: 2006-11-14 - -@date: 2006-09-24 - -@language.document: English - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{Debian Project}http://www.debian.org/ -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Site map}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.
Version 1.3 ratified on September 24th, 2006. Supersedes Version 1.2 ratified on October 29th, 2003 and Version 1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 ratified on December 2nd, 1998.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.3.adjusted.sst,v 1.1 2006/11/23 01:36:16 ralph Exp ralph $ - -:A~ Debian Constitution - -:B~ Constitution for the Debian Project (v1.3) - -1~pre [Prefix]-# - -{Version 1.3}http://www.debian.org/devel/constitution.1.3 ratified on September 24th, 2006. Supersedes {Version 1.2}http://www.debian.org/devel/constitution.1.2 ratified on October 29th, 2003 and {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998. - -1~ Introduction - -/{The Debian Project is an association of individuals who have made common cause to create a free operating system.}/ - -This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process. - -1~ Decision-making bodies and individuals - -Each decision in the Project is made by one or more of the following: - -# The Developers, by way of General Resolution or an election; - -# The Project Leader; - -# The Technical Committee and/or its Chairman; - -# The individual Developer working on a particular task; - -# Delegates appointed by the Project Leader for specific tasks; - -# The Project Secretary. - -Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later. - -2~ General rules - -# Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. - -# A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. - -# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly. - -1~ Individual Developers - -2~ Powers - -An individual Developer may - -# make any technical or nontechnical decision with regard to their own work; - -# propose or sponsor draft General Resolutions; - -# propose themselves as a Project Leader candidate in elections; - -# vote on General Resolutions and in Leadership elections. - -2~ Composition and appointment - -# Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile. - -# The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2. - -2~ Procedure - -Developers may make these decisions as they see fit. - -1~ The Developers by way of General Resolution or election - -2~ Powers - -Together, the Developers may: - -# Appoint or recall the Project Leader. - -# Amend this constitution, provided they agree with a 3:1 majority. - -# Make or override any decision authorised by the powers of the Project Leader or a Delegate. - -# Make or override any decision authorised by the powers of the Technical Committee, provided they agree with a 2:1 majority. - -# Issue, supersede and withdraw nontechnical policy documents and statements. - -These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. - -They may also include position statements about issues of the day. - -_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes. - -_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines. - -_# A Foundation Document requires a 3:1 majority for its supersession. New Foundation Documents are issued and existing ones withdrawn by amending the list of Foundation Documents in this constitution. - -# Make decisions about property held in trust for purposes related to Debian. (See §9.). - -# In case of a disagreement between the project leader and the incumbent secretary, appoint a new secretary. - -2~ Procedure - -# The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. - -# Delaying a decision by the Project Leader or their Delegate: - -_# If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see §4.1(3). - -_# If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). - -_# If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. - -_# If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. - -_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted. - -# Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. - -# The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. - -# Proposals, sponsors, amendments, calls for votes and other formal actions are made by announcement on a publicly-readable electronic mailing list designated by the Project Leader's Delegate(s); any Developer may post there. - -# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes. - -# Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded. - -1~ Project Leader - -2~ Powers - -The {Project Leader}http://www.debian.org/devel/leader may: - -# Appoint Delegates or delegate decisions to the Technical Committee. - -The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. - -Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility. - -# Lend authority to other Developers. - -The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question. - -# Make any decision which requires urgent action. - -This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline. - -# Make any decision for whom noone else has responsibility. - -# Propose draft General Resolutions and amendments. - -# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) - -# Use a casting vote when Developers vote. - -The Project Leader also has a normal vote in such ballots. - -# Vary the discussion period for Developers' votes (as above). - -# Lead discussions amongst Developers. - -The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. - -# In consultation with the developers, make decisions affecting property held in trust for purposes related to Debian. (See §9.). Such decisions are communicated to the members by the Project Leader or their Delegate(s). Major expenditures should be proposed and debated on the mailing list before funds are disbursed. - -# Add or remove organizations from the list of trusted organizations (see §9.3) that are authorized to accept and hold assets for Debian. The evaluation and discussion leading up to such a decision occurs on an electronic mailing list designated by the Project Leader or their Delegate(s), on which any developer may post. There is a minimum discussion period of two weeks before an organization may be added to the list of trusted organizations. - -2~ Appointment - -# The Project Leader is elected by the Developers. - -# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately. - -# For the following three weeks any Developer may nominate themselves as a candidate Project Leader. - -# For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary. - -# The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. - -# The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. - -# The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is "None Of The Above". - -# The Project Leader serves for one year from their election. - -2~ Procedure - -The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. - -Where practical the Project Leader should informally solicit the views of the Developers. - -The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader. - -1~ Technical committee - -2~ Powers - -The {Technical Committee}http://www.debian.org/devel/tech-ctte may: - -# Decide on any matter of technical policy. - -This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).) - -# Decide any technical matter where Developers' jurisdictions overlap. - -In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter. - -# Make a decision when asked to do so. - -Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it. - -# Overrule a Developer (requires a 3:1 majority). - -The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. - -# Offer advice. - -The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee. - -# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.) - -# Appoint the Chairman of the Technical Committee. - -The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. - -# The Chairman can stand in for the Leader, together with the Secretary - -As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. - -2~ Composition - -# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. - -# When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. - -# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. - -# When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. - -# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. - -2~ Procedure - -# The Technical Committee uses the Standard Resolution Procedure. - -A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. - -# Details regarding voting - -The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote). - -# Public discussion and decision-making. - -Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee. - -# Confidentiality of appointments. - -The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public. - -# No detailed design work. - -The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. - -The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. - -/{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/ - -# Technical Committee makes decisions only as last resort. - -The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. - -1~ The Project Secretary - -2~ Powers - -The {Secretary:}http://www.debian.org/devel/secretary - -# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution. - -# Can stand in for the Leader, together with the Chairman of the Technical Committee. - -If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. - -# Adjudicates any disputes about interpretation of the constitution. - -# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time. - -2~ Appointment - -The Project Secretary is appointed by the Project Leader and the current Project Secretary. - -If the Project Leader and the current Project Secretary cannot agree on a new appointment, they must ask the Developers by way of General Resolution to appoint a Secretary. - -If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary. - -The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed. - -2~ Procedure - -The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers. - -When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. - -1~ The Project Leader's Delegates - -2~ Powers - -The Project Leader's Delegates: - -# have powers delegated to them by the Project Leader; - -# may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. - -2~ Appointment - -The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made. - -2~ Procedure - -Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. - -1~ Assets held in trust for Debian - -In most jurisdictions around the world, the Debian project is not in a position to directly hold funds or other property. Therefore, property has to be owned by any of a number of organisations as detailed in §9.2. - -Traditionally, SPI was the sole organisation authorized to hold property and monies for the Debian Project. SPI was created in the U.S. to hold money in trust there. - -SPI and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. - -2~ Relationship with Associated Organizations - -# Debian Developers do not become agents or employees of organisations holding assets in trust for Debian, or of each other, or of persons in authority in the Debian Project, solely by the virtue of being Debian Developers. A person acting as a Developer does so as an individual, on their own behalf. Such organisations may, of their own accord, establish relationships with individuals who are also Debian developers. - -2~ Authority - -# An organisation holding assets for Debian has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by the organisation shall require it to act outside its legal authority. - -# Debian claims no authority over an organisation that holds assets for Debian other than that over the use of property held in trust for Debian. - -2~ Trusted organisations - -Any donations for the Debian Project must be made to any one of a set of organisations designated by the Project leader (or a delegate) to be authorized to handle assets to be used for the Debian Project. - -Organisations holding assets in trust for Debian should undertake reasonable obligations for the handling of such assets. - -Debian maintains a public List of Trusted Organisations that accept donations and hold assets in trust for Debian (including both tangible property and intellectual property) that includes the commitments those organisations have made as to how those assets will be handled. - -1~a A. Standard Resolution Procedure - -These rules apply to communal decision-making by committees and plebiscites, where stated above. - -2~a1 A.1. Proposal - -The formal procedure begins when a draft resolution is proposed and sponsored, as required. - -2~a1a A.1 Discussion and Amendment - -# Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. - -# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. - -# If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. - -# If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).) - -# The proposer or a resolution may suggest changes to the wordings of amendments; these take effect if the proposer of the amendment agrees and none of the sponsors object. In this case the changed amendments will be voted on instead of the originals. - -# The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the minimum discussion period is not restarted. - -2~a2 A.2. Calling for a vote - -# The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. - -# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. - -# The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). - -# The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. - -2~a3 A.3. Voting procedure - -# Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). - -# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. - -# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise. - -# In cases of doubt the Project Secretary shall decide on matters of procedure. - -2~a4 A.4. Withdrawing resolutions or unaccepted amendments - -The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already. - -A sponsor of a resolution or amendment (unless it has been accepted) may withdraw. - -If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires. - -2~a5 A.5. Expiry - -If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. - -The secretary may also include suggestions on how to proceed, if appropriate. - -2~a6 A.6. Vote Counting - -# Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes. - -# If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. - -# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. - -_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. - -_# An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). - -_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. - -# From the list of undropped options, we generate a list of pairwise defeats. - -_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A). - -# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats. - -_# An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C. - -# We construct the Schwartz set from the set of transitive defeats. - -_# An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A. - -# If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5. - -_# A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). - -_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat. - -# If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. - -!_ Note: -Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. - -/{When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.}/ - -1~b B. Use of language and typography - -The present indicative ('is', for example) means that the statement is a rule in this constitution. 'May' or 'can' indicates that the person or body has discretion. `Should' means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~da.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~da.sst deleted file mode 100644 index 78486a96..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~da.sst +++ /dev/null @@ -1,517 +0,0 @@ -% SiSU 0.38 - -@title: Debians vedtægter - -@subtitle: Debian-projektets vedtægter (v1.3) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2003-10-29 - -@date.available: 2003-10-29 - -@date.modified: 2003-10-29 - -@date: 2003-10-29 - -@language.document: Danish - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).
"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Version 1.3 blev godkendt den 24. september 2006. Erstatter version 1.2 godkendt den 29. oktober 2003 og version 1.1 godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998.
Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2~dk.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debians vedtægter - -:B~ Debian-projektets vedtægter (v1.3) - -1~pre [Prefix]-# - -{ Version 1.3 }http://www.debian.org/devel/constitution.1.3 blev godkendt den 24. september 2006. Erstatter { version 1.2 }http://www.debian.org/devel/constitution.1.2 godkendt den 29. oktober 2003 og { version 1.1 }http://www.debian.org/devel/constitution.1.1 godkendt den 21. juni 2003, der erstattede { version 1.0 }http://www.debian.org/devel/constitution.1.0 som blev godkendt den 2. december 1998. - -1~1 § 1. Introduktion - -Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem. - -Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen. - -1~2 § 2. Beslutningsdygtige organer og -personer - -Enhver beslutning i projektet er omfattet af en eller flere af følgende: - -# Udviklerne, via en fælles resolution eller et valg; - -# Projektlederen; - -# Den tekniske komité og/eller dennes formand; - -# Den individuelle udvikler som arbejder med en bestemt opgave; - -# Delegater udnævnt af projektlederen til at varetage særlige opgaver; - -# Projektsekretæren. - -Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere. - -2~2.1 § 2.1. Generelle regler - -# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne. - -# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat. - -# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette. - -1~3 § 3. Individuelle udviklere - -2~3.1 § 3.1. Fuldmagt - -En individuel udvikler kan - -# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde; - -# foreslå og støtte udkast til generelle resolutioner; - -# foreslå sig selv som kandidat til projektleder i valg; - -# stemme på generelle resolutioner og i ledervalg. - -2~3.2 § 3.2. Sammensætning og udnævnelse - -# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt. - -# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se § 4.1(3) og § 4.2. - -2~3.3 § 3.3. Fremgangsmåder - -Udviklerne kan foretage disse beslutninger efter eget skøn. - -1~4 § 4. Udviklerne via generel resolution eller et valg - -2~4.1 § 4.1. Fuldmagt - -Udviklerne kan sammen: - -# Udnævne eller afsætte projektlederen. - -# Ændre disse vedtægter med et 3:1-flertal. - -# Træffe eller ophæve enhver beslutning autoriseret af projektlederen eller en delegat. - -# Træffe eller ophæve enhver beslutning autoriseret af den tekniske komité, såfremt de er enige med et 2:1-flertal. - -# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer. - -Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til. - -Det kan også være stillingtagen til aktuelle emner. - -_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål. - -_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software. - -_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter. - -# Træffe beslutninger om forvaltede ejendele til formål med relation til Debian. (Se § 9.1). - -# I tilfælde af uenighed mellem projektlederen og den nuværende sekretær, udnævne en ny sekretær. - -2~4.2 § 4.2. Fremgangsmåde - -# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité. - -# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater: - -_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se § 4.1(3). - -_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette). - -_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen. - -_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning. - -_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt. - -# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge. - -# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q. - -# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den. - -# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer. - -# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke. - -1~5 § 5. Projektlederen - -2~5.1 § 5.1. Fuldmagt - -Projektlederen kan: - -# Udnævne delegater eller uddelegere beslutninger til den tekniske komité. - -Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité. - -Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage. - -# Give hjemmel til andre udviklere. - -Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning. - -# Foretage beslutninger som kræver omgående handling. - -Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist. - -# Foretage beslutninger som ingen andre har ansvaret for. - -# Fremstille udkast til generelle resolutioner og ændringsforslag. - -# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se § 6.2.) - -# Afgive en afgørende stemme i udviklernes afstemninger. - -Projektlederen har også almindelig stemmeret i sådanne afstemninger. - -# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor). - -# Lede diskussioner blandt udviklerne. - -Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter. - -# I konsultation med udviklerne, træffe beslutninger der vedrører forvaltede ejendele i forbindelse med Debian. (Se § 9.). Sådanne beslutninger kommunikeres til medlemmerne af projektlederen eller dennes delegat(er). Større udgifter skal foreslås og diskuteres på postlisten før beløbet erlægges. - -# Tilføje eller fjerne organisationer fra listen over betroede organisationer (se § 9.3) som er autoriserede til at modtage og være i besiddelse af ejendele for Debian. Evaluering og diskussion førende til sådanne beslutninger finder sted på en elektronisk postliste udpeget af projektlederen eller denne delgat(er), på hvilken alle udviklere må skrive. Der er en minimal diskussionstid på to uger før en organisation må blive føjet til listen over betroede organisationer. - -2~5.2 § 5.2. Udnævnelse - -# Projektlederen vælges af udviklerne. - -# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående. - -# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat. - -# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange. - -# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet. - -# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange. - -# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit § A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§ 4.2), og standardvalget er Ingen af de nævnte. - -# Projektlederen vælges for et år ad gangen. - -2~5.3 § 5.3. Fremgangsmåde - -Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne. - -Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter. - -Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder. - -1~6 § 6. Teknisk komité - -2~6.1 § 6.1. Fuldmagt - -Den tekniske komité kan: - -# Træffe beslutninger om tekniske retningslinier. - -Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se § 6.3(5).) - -# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper. - -I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen. - -# Træffe en beslutning når den bliver bedt om at gøre dette. - -Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den. - -# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal) - -Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes. - -# Give råd. - -Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter. - -# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se § 6.2.) - -# Udnævne formanden for den tekniske komité. - -Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i § A.6 i de generelle resolutionsprocedurer. - -# Formanden kan vikariere for lederen, sammen med sekretæren - -Som beskrevet i § 7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder. - -2~6.2 § 6.2. Sammensætning - -# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer. - -# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej. - -# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks. - -# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse. - -# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité. - -2~6.3 § 6.3. Fremgangsmåde - -# Den tekniske komité anvender den generelle resolutionsprocedure. - -Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to. - -# Detaljerede afstemningoplysninger - -Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret). - -# Offentlig diskussion og afgørelser - -Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen. - -# Fortrolighed ved udnævnelser - -Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres. - -# Ikke et detaljeret udviklingsarbejde - -Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora. - -Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder. - -Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde. - -# Den teknisk komité træffer kun afgørelser som en sidste udvej - -Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette. - -1~7 § 7. Projektsekretæren - -2~7.1 § 7.1. Fuldmagt - -Sekretæren: - -# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne. - -# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité. - -Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette. - -# Dømmer i stridigheder om tolkning af vedtægterne. - -# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage. - -2~7.2 § 7.2. Udnævnelse - -Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær. - -Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede udviklerne om at udnævne en ny sekretær gennem en generel beslutning. - -Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær. - -Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig. - -2~7.3 § 7.3. Fremgangsmåde - -Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne. - -Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne. - -1~8 § 8. Projektlederens delegater - -2~8.1 § 8.1. Fuldmagt - -Projektlederens delegater: - -# har fået uddelegeret en fuldmagt fra projektlederen; - -# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab. - -2~8.2 § 8.2. Udnævnelse - -Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat. - -2~8.3 § 8.3. Fremgangsmåde - -Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus. - -1~9 § 9. Ejendele der forvaltes på vegne af Debian - -I de fleste af verdens jurisdiktioner er Debian-projektet ikke i en situation hvor det direkte må være i besiddelse af midler eller andre ejendele. Derfor er det nødvendigt at ejendele ejes af enhver af en række organisationer, som beskrevet i § 9.2. - -Traditionelt var SPI den eneste organisation, der var autoriseret til at forvalte ejendele og beløb for Debian-projektet. SPI blev etableret i USA, for der at forvalte beløb. - -SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder. - -2~9.1 § 9.1. Relationer til tilknyttede organisationer - -# Debian-udviklere bliver ikke agenter for eller ansatte af organisationer der forvalter ejendele for Debian, eller af hinanden, eller af persioner med myndighed i Debian-projektet, blot ved at være Debian-udviklere. En person der fungerer som udvikler gør dette som en individuel person, på egne vegne. Sådanne organisationer kan, af egen kraft, etablere relationer mellem individer der også er Debian-udviklere. - -2~9.2 § 9.2. Autoritet - -# En organisation der forvalter ejendele for Debian har ingen autoritet over Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger taget af Debian hvad angår ejendele der forvaltes af organisationen må kræve at denne handler uden for sin juridiske autoritet. - -# Debian har ingen autoritet over en organisation der forvalter ejendele for Debian, bortset fra over de ejendele der forvaltes for Debian. - -2~9.3 Betroede organisationer - -Alle donationer til Debian-projektet skal ske til en af de organisationer, som projektlederen (eller en delegat) har autoriseret til at forvalte ejendele til anvendelse af Debian-projektet. - -Organisationer der forvalter ejendele for Debian bør påtage sig passende forpligtelser ved forvaltning af sådanne ejendele. - -Debian vedligeholder en offentlig liste over betroede organisationer, der accepterer donationer og forvalter ejendele for Debian (deriblandt håndgribelige og intellektuelle ejendele), indeholdende disse organisationers tilsagn til hvordan disse ejendele vil blive forvaltet. - -1~a A. Generel resolutionsprocedure - -Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor. - -2~a1 A.1. Forslag - -Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet. - -2~a1a A.1. Diskussion og ændring - -# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag. - -# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres. - -# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette. - -# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).) - -# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige. - -# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen. - -2~a2 A.2. Afstemning - -# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået. - -# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag. - -# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4). - -# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret. - -2~a3 A.3. Afstemningsprocedure - -# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt). - -# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav. - -# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet. - -# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål. - -2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag - -Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det. - -En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret). - -Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber. - -2~a5 A.5. Udløb - -Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage. - -Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat. - -2~a6 A.6. Stemmeoptælling - -# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen. - -# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning. - -# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning. - -_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B. - -_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A). - -_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1. - -# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag. - -_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A). - -# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag. - -_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C. - -# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt. - -_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt. - -# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5. - -_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B). - -_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag. - -# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen. - -Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable. - -Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes. - -1~b B. Brug af sprog og typografi - -Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde. - -Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser. - -% Deutsch English español français Italiano 日本語 (Nihongo) polski Português Русский (Russkij) svenska - -% Sådan opsætter du standardsprogvalg for dokumenter - -% For at rapportere et problem med webstedet sendes en e-mail på engelsk til debian-www@lists.debian.org. Se Debians kontaktside for andre kontaktoplysninger. - -% Senest opdateret: Tirs 14. nov 2006 kl. 15.41.07 UTC -% Ophavsretsbeskyttet © 1997-2006 SPI; Se licensbetingelserne -% Debian er et registreret varemærke tilhørende Software in the Public Interest, Inc. - -% Debian-projektet - -% Vælg en server i nærheden af dig - -% Spring navigering over - -% * Om Debian -% * Nyheder -% * Få fat i Debian -% * Support -% * Udviklerhjørnet -% * Sideoversigt -% * Søg diff --git a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~de.sst b/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~de.sst deleted file mode 100644 index 63cbd6d6..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.3~de.sst +++ /dev/null @@ -1,505 +0,0 @@ -% SiSU 0.38 - -% Zuletzt geändert: Mittwoch den 15. Nov 2006 um 22:29:40 Uhr UTC -% Copyright © 1997-2006 SPI; Hier die Lizenzbestimmungen -% Debian ist ein eingetragenes Warenzeichen von Software in the Public Interest, Inc. - -@title: Debian-Verfassung - -@subtitle: Verfassung für das Debian-Projekt (v1.3) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1998-12-03 - -@date.issued: 1998-12-03 - -@date.valid: 2006-09-24 - -@date.available: 2006-09-24 - -@date.modified: 2006-11-15 - -@date: 2003-10-29 - -@language.document: German - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.de.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/devel/constitution -{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html -{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.
Dies ist die am 24. September 2006 ratifizierte Version 1.3. Sie ersetzt die am 29. Oktober 2003 ratifizierte Version 1.2 und die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.
Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.
Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.3.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original - -@rcs: $Id: debian_constitution_v1.2~de.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debian-Verfassung - -:B~ Verfassung für das Debian-Projekt (v1.3) - -1~pre [Prefix]-# - -Dies ist die am 24. September 2006 ratifizierte { Version 1.3 }http://www.debian.org/devel/constitution.1.3. Sie ersetzt die am 29. Oktober 2003 ratifizierte { Version 1.2 }http://www.debian.org/devel/constitution.1.2 und die am 21. Juni 2003 ratifizierte { Version 1.1 }http://www.debian.org/devel/constitution.1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte { Version 1.0 }http://www.debian.org/devel/constitution.1.0 ersetzt. - -1~ Einleitung - -/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystems zu ihrem gemeinsamen Anliegen gemacht haben.}/ - -Dieses Dokument beschreibt die Organisationsstruktur für formelle Entscheidungsfindung innerhalb des Projekts. Es beschreibt nicht die Ziele des Projekts oder wie es diese erreicht, und es enthält keine Richtlinien außer denen, die sich direkt auf den Prozess der Entscheidungsfindung beziehen. - -2~ Entscheidungsfindende Organe und Einzelpersonen - -Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen: - -# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl. - -# Dem Projektleiter; - -# Dem Technischen Ausschuss und/oder seinem Vorsitzenden; - -# Dem an einer einzelnen Aufgabe arbeitenden Entwickler; - -# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten; - -# Dem Projekt-Schriftführer. - -Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse dieser Organe, ihre Zusammensetzung und Ernennung und das Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person oder eines Organs können der Überwachung und/oder Einschränkung durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen. - -2~ Allgemeine Vorschriften - -# Nichts in dieser Verfassung erlegt irgendjemandem die Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine Person, die eine an sie delegierte oder ihr zugewiesene Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch darf sie nicht diesen Vorschriften oder Entscheidungen, die nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv entgegenwirken. - -# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann. - -# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt. - -1~ Einzelne Entwickler - -2~ Befugnisse - -Ein einzelner Entwickler darf - -# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen; - -# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten; - -# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen; - -# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen. - -2~ Zusammensetzung und Ernennung - -# Entwickler sind Freiwillige, die sich darin einig sind, die Ziele des Projekts insofern zu fördern, als sie an ihm teilhaben, und die ein oder mehrere Pakete für das Projekt betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten. - -# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2. - -2~ Verfahren - -Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten. - -1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl - -2~ Befugnisse - -Zusammen können die Entwickler - -# Den Projektleiter ernennen oder abberufen. - -# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu. - -# Jede Entscheidung treffen oder außer Kraft setzen, zu der der Projektleiter oder einer seiner Delegierten befugt ist. - -# Jede Entscheidung treffen oder außer Kraft setzen, zu der der Technische Ausschuss befugt ist, vorausgesetzt sie stimmen diesem mit einer 2:1-Mehrheit zu. - -# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen. - -Diese beinhalten Dokumente, welche die Ziele des Projekts und seine Beziehung zu anderen Gebilden der Freien Software beschreiben, sowie nicht-technische Richtlinien wie die Lizenzbedingungen für Freie Software, die Debian-Software erfüllen muss. - -Sie können auch Positionserklärungen zu Tagesfragen hinzufügen. - -_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden. - -_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software. - -_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen. - -# Entscheidungen über treuhänderisch verwaltetes Eigentum treffen, welches mit den Zwecken von Debian in Beziehung steht. (Siehe §9.) - -# Im Falle einer Meinungsverschiedenheit zwischen dem Projektleiter und dem amtierenden Schriftführer einen neuen Schriftführer ernennen. - -2~ Verfahren - -# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird. - -# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten: - -_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3). - -_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies). - -_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können. - -_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, bis die vollständige Abstimmung über die Entscheidung durchgeführt wurde, oder ob die Erfüllung der ursprünglichen Entscheidung bis dahin verzögert wird. Es gibt bei dieser unmittelbaren verfahrensbezogenen Abstimmung kein Quorum. - -_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt. - -# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. - -# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q. - -# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben. - -# Stimmen werden in einer für den Schriftführer geeigneten Weise durch E-Mail abgegeben. Der Schriftführer legt für jede Abstimmung fest, ob die Abstimmenden ihre Stimme ändern können. - -# Q ist die Hälfte der Quadratwurzel aus der Anzahl der gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches davon kleiner ist. Q und K brauchen nicht ganze Zahlen sein und werden nicht gerundet. - -1~ Projektleiter - -2~ Befugnisse - -Der Projektleiter darf - -# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren. - -Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben. - -Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen. - -# Anderen Entwicklern Vollmacht erteilen. - -Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen. - -# Jede Entscheidung treffen, welche dringende Handlung erfordert. - -Dies gilt nicht für Entscheidungen, die nur durch einen Mangel an entsprechenden Maßnahmen allmählich dringend geworden sind, außer wenn es einen festen Stichtag gibt. - -Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt. - -# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen. - -# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.) - -# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen. - -Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen. - -# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben). - -# Diskussionen unter Entwicklern leiten. - -Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern. - -# Im Einvernehmen mit den Entwicklern Entscheidungen fällen, die treuhänderisch verwaltetes Eigentum betreffen, welches mit den Zwecken von Debian in Beziehung steht. (Siehe §9.) Solche Entscheidungen werden den Mitgliedern durch den Projektleiter oder dessen Delegierte(n) mitgeteilt. Bedeutendere Ausgaben sollten beantragt und auf den Mailinglisten debattiert werden, bevor Gelder ausgezahlt werden. - -# Der Liste von vertrauenswürdigen Organisationen (siehe §9.3) Organisationen hinzufügen oder entfernen, die befugt sind, für Debian Vermögen anzunehmen und zu verwalten. Die zu einer solchen Entscheidung führende Beurteilung und Diskussion findet auf einer vom Projektleiter oder seines/seiner Delegierten bestimmten Mailingliste statt, auf der jeder Entwickler Beiträge abgeben kann. Es besteht eine Diskussionsfrist von mindestens zwei Wochen, bevor eine Organisation der Liste vertrauenswürdiger Organisationen hinzugefügt werden kann. - -2~ Ernennung - -# Der Projektleiter wird von den Entwicklern gewählt. - -# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort. - -# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren. - -# Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne nutzen (um ihre Person und Positionen bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt. - -# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist. - -# Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich Niemand von den Obigen. Falls Niemand von den Obigen die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig. - -# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist Niemand von den Obigen. - -# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang. - -2~ Verfahren - -Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind. - -Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen. - -Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft. - -1~ Technischer Ausschuss - -2~ Befugnisse - -Der Technische Ausschuss darf - -# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft. - -Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).) - -# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen. - -In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden. - -# Eine Entscheidung treffen, wenn er darum gebeten wird. - -Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen. - -# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit). - -Der Technische Ausschuss kann einen Entwickler darum bitten, einen bestimmten technischen Handlungsweg zu beschreiten, sogar wenn der Entwickler dies nicht wünscht; dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der Ausschuss festlegen, dass eine Beanstandung, die vom Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt werden sollte. - -# Rat anbieten. - -Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben. - -# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.) - -# Den Vorsitzenden des Technischen Ausschusses ernennen. - -Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern gewählt. Alle Mitglieder des Ausschusses werden automatisch nominiert; der Ausschuss beginnt eine Woche vor dem Freiwerden des Amtes zu wählen (oder sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt. - -# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten. - -Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt. - -2~ Zusammensetzung - -# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben. - -# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht. - -# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht. - -# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung. - -# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen. - -2~ Verfahren - -# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens. - -Ein Beschlussentwurf oder eine Abänderung kann von jedem Mitglied des Technischen Ausschusses vorgeschlagen werden. Es gibt keine Mindestfrist für Diskussionen; die Abstimmungsfrist dauert bis zu einer Woche, oder bis über den Ausgang kein Zweifel mehr besteht. Mitglieder können ihre Stimmen ändern. Das Quorum beträgt 2. - -# Einzelheiten, die die Abstimmung betreffen. - -Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der Technische Ausschuss darüber abstimmt, ob ein Entwickler, der ebenfalls Mitglied des Ausschusses ist, überstimmt werden soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er ist der Vorsitzende – in diesem Fall kann er nur seine ausschlaggebende Stimme benutzen). - -# Öffentliche Diskussion und Entscheidungsfindung. - -Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss. - -# Vertraulichkeit der Ernennungen. - -Der Technische Ausschuss kann vertrauliche Diskussionen durch private E-Mail, eine private Mailingliste oder andere Mittel abhalten, um Ernennungen in den Ausschuss zu diskutieren. Jedoch müssen Abstimmungen über Ernennungen öffentlich sein. - -# Keine Entwurfsarbeit in Einzelheiten. - -Der Technische Ausschuss nimmt nicht am Entwurf neuer Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit sollte von Einzelpersonen für sich oder zusammen durchgeführt werden und in gewöhnlichen Foren für technische Richtlinien und Entwürfe diskutiert werden. - -Der Technische Ausschuss beschränkt sich darauf, Kompromisse zwischen Lösungen und Entscheidungen, welche anderswo vorgeschlagen und hinreichend gründlich diskutiert worden sind, auszuwählen oder aufzunehmen. - -Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben. - -# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg. - -Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden und fehlgeschlagen sind, außer wenn er von der Person oder dem Organ, das normalerweise dafür verantwortlich ist, darum gebeten wurde, eine Entscheidung zu treffen. - -1~ Der Projekt-Schriftführer - -2~ Befugnisse - -Der Schriftführer - -# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert. - -# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten. - -Wenn es keinen Projektleiter gibt, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer in gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie dies als unumgänglich betrachten. - -# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft. - -# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen. - -2~ Ernennung - -Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt. - -Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie die Entwickler auf dem Weg eines Allgemeinen Beschlusses darum bitten, einen Schriftführer zu ernennen. - -Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des Technischen Ausschusses als stellvertretender Schriftführer die Entscheidung treffen oder delegieren. - -Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss. - -2~ Verfahren - -Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind. - -Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind. - -1~ Die Delegierten des Projektleiters - -2~ Befugnisse - -Die Delegierten des Projektleiters - -# haben vom Projektleiter an sie delegierte Befugnisse; - -# dürfen gewisse Entscheidungen treffen, die der Leiter nicht auf direkte Weise treffen darf. Dazu gehört, Entwickler anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu bestimmen, die keine Pakete betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern. - -2~ Ernennung - -Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter kann weder die Position des Delegierten von bestimmten Entscheidungen des Delegierten abhängig machen, noch kann er sich über eine Entscheidung hinwegsetzen, die einmal von einem Delegierten getroffen wurde. - -2~ Verfahren - -Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen. - -1~ Für Debian treuhänderisch verwaltetes Vermögen - -In den meisten Gerichtsbarkeiten auf der Welt ist Debian nicht in der Lage, direkt Vermögen oder anderes Eigentum zu besitzen. Daher muss Eigentum von einer Reihe von Organisationen besessen werden, wie in §9.2 genauer beschrieben wird. - -Traditionell war SPI die einzige Organisation, die befugt war, Eigentum und Gelder für das Debian-Projekt zu besitzen. SPI wurde in den Vereinigten Staaten gegründet, um dort Geld treuhänderisch zu verwalten. - -SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet. - -2~ Beziehung zu angegliederten Organisationen - -# Debian-Entwickler werden nicht allein durch den Vorzug, Debian-Entwickler zu sein, Beauftragte oder Angestellte von für Debian treuhänderisch Vermögen verwaltenden Organisationen, oder voneinander, oder von Personen mit Befugnis im Debian-Projekt. Eine als Entwickler handelnde Person tut dies als Einzelperson, im eigenen Namen. Solche Organisationen dürfen jedoch aus eigenem Antrieb Beziehungen zu Einzelpersonen unterhalten, die auch Debian-Entwickler sind. - -2~ Befugnisse - -# Eine Organisation, welche für Debian Vermögen verwaltet, hat keine Befugnis hinsichtlich Debians technischer oder nichttechnischer Entscheidungen, außer, dass keine von Debians Entscheidungen bezüglich irgendwelchen von der Organisation verwalteten Eigentums von der Organisation verlangen möge, außerhalb ihrer rechtlichen Befugnis zu handeln. - -# Debian beansprucht keine Befugnis über eine Organisation, welche Vermögen für Debian verwaltet, außer der Benutzung des für Debian treuhänderisch verwalteten Eigentums. - -2~ 9.3. Vertrauenswürdige Organisationen - -Jegliche Spenden für das Debian-Projekt müssen an eine aus einer Reihe von Organisationen gehen, die vom Projektleiter (oder eines Delegierten) dazu ernannt wurden, für den Umgang mit für das Debian-Projekt verwendetem Vermögen befugt zu sein. - -Organisationen, die für Debian Vermögen treuhänderisch verwalten, sollten für den Umgang mit diesem Vermögen angemessene Verpflichtungen eingehen. - -Debian unterhält eine öffentliche Liste von vertrauenswürdigen Organisationen (List of Trusted Organisations), die Spenden annehmen und für Debian Vermögen treuhänderisch verwalten (hierbei sind sowohl Sachvermögen als auch geistiges Eigentum inbegriffen). Die Liste enthält sowohl die Verpflichtungen, die diese Organisationen eingehen, als auch wie mit diesem Vermögen umgegangen wird. - -1~a A. Standard-Beschlussverfahren - -Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben. - -2~a1 A.1. Beantragung - -Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf. - -2~a1a A.1. Diskussion und Abänderung - -# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses. - -# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht. - -# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses nicht mit der Annahme durch den Antragsteller einer formellen Abänderung einverstanden ist, bleibt die Abänderung eine Abänderung und es wird über sie abgestimmt. - -# Wenn eine vom ursprünglichen Antragsteller angenommene Abänderung nicht nach dem Geschmack Anderer ist, können diese eine weitere Abänderung einbringen, um die frühere Veränderung umzukehren (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein). - -# Der Antragsteller eines Beschlusses kann Veränderungen an der Formulierung von Abänderungen vorschlagen; diese werden wirksam, wenn der Antragsteller der Abänderung damit einverstanden ist und keiner der Befürworter dagegen ist. In diesem Fall wird anstelle der ursprünglichen über die veränderten Abänderungen abgestimmt. - -# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende Fehler (zum Beispiel Schreibfehler oder Ungereimtheiten) zu berichtigen, oder Veränderungen vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand erhebt innerhalb von 24 Stunden Einwände. In diesem Fall beginnt die Mindestfrist für Diskussionen nicht von vorn. - -2~a2 A.2. Aufruf zur Abstimmung - -# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist. - -# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen. - -# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter Abänderungen sind, und folglich, welche Form der Stimmzettel annehmen sollte. Dennoch liegt die endgültige Entscheidung über die Form des/der Stimmzettel beim Schriftführer – siehe §§7.1(1), 7.1(3) und A.3(4). - -# Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt, zu dem die letzte formelle Abänderung angenommen wurde, oder ab dem Zeitpunkt, zu dem der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden. - -2~a3 A.3. Wahlverfahren - -# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält. - -# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit. - -# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt Weitere Diskussion, wenn nicht eine andere bestimmt wurde. - -# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens. - -2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen - -Der Antragsteller eines Beschlusses oder einer nicht angenommenen Abänderung kann diese zurückziehen. In diesem Fall können neue Antragsteller hervortreten, um sie am Leben zu halten; dann wiederum wird die erste Person, die dies tut, der neue Antragsteller, und alle anderen werden Befürworter, wenn sie dies nicht bereits sind. - -Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen. - -Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt. - -2~a5 A.5. Verfall - -Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder auf andere Weise behandelt wurde, kann der Schriftführer eine Erklärung abgeben, dass man dabei ist, die Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der Anträge innerhalb einer Woche Einwände erhebt, wird die Angelegenheit zurückgezogen. - -Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll. - -2~a6 A.6. Stimmenzählung - -# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den Aufruf zur Abstimmung aufgenommen. - -# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen. - -# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen. - -_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen. - -_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist. - -_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1. - -# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen. - -_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist. - -# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen. - -_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt. - -# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen. - -_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt. - -# Wenn es Besiegungen zwischen Wahlmöglichkeiten gibt, die in der Schwartzschen Menge liegen, so lassen wir die schwächste solcher Besiegungen aus der Liste der paarweisen Besiegungen fallen und kehren zu Schritt 5 zurück. - -_# Eine Besiegung (A,X) ist schwächer als eine Besiegung (B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist (A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist, und V(X,A) größer als V(Y,B) ist. - -_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben. - -# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt. - -Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden. - -Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind. - -1~b B. Sprachgebrauch und Typographie - -Der Präsens Indikativ (zum Beispiel ist) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung ist. Darf oder kann zeigt an, dass es im Ermessen der Person oder des Organs liegt. Sollte bedeutet, dass es als gute Sache betrachtet würde, wenn der Satz befolgt würde, aber er ist nicht bindend. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen. - -Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich. - - - -% Dies ist die am 24. September 2006 ratifizierte -% Version 1.3. Sie ersetzt die am 29. Oktober 2003 -% ratifizierte Version 1.2 und die am 21. Juni 2003 -% ratifizierte Version 1.1, welche ihrerseits die am -% 2. Dezember 1998 ratifizierte Version 1.0 ersetzt. diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1.sst deleted file mode 100644 index 3d2b95e5..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1.sst +++ /dev/null @@ -1,140 +0,0 @@ -% SiSU 0.38 - -@title: Debian Social Contract - -@subtitle: (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: English - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1.s3,v 1.4 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debian Social Contract - -1~pre [Prefix]-# - -Version 1.1 ratified on April 26, 2004. Supersedes {Version 1.0}http://www.debian.org/social_contract.1.0 ratified on July 5, 1997. - -Debian, the producers of the Debian GNU/Linux system, have created the *{Debian Social Contract}*. The {Debian Free Software Guidelines (DFSG)}http://www.debian.org/social_contract#guidelines part of the contract, initially designed as a set of commitments that we agree to abide by, has been adopted by the free software community as the basis of the {Open Source Definition.}http://www.opensource.org/docs/definition_plain.html - -1~ Social Contract with the Free Software Community - -2~ 1. Debian will remain 100% free - -We provide the guidelines that we use to determine if a work is "free" in the document entitled "The Debian Free Software Guidelines". We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. - -2~ 2. We will give back to the free software community - -When we write new components of the Debian system, we will license them in a manner consistent with the Debian Free Software Guidelines. We will make the best system we can, so that free works will be widely distributed and used. We will communicate things such as bug fixes, improvements and user requests to the "upstream" authors of works included in our system. - -2~ 3. We will not hide problems - -We will keep our entire bug report database open for public view at all times. Reports that people file online will promptly become visible to others. - -2~ 4. Our priorities are our users and free software - -We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system. - -2~ 5. Works that do not meet our free software standards - -We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian. We encourage CD manufacturers to read the licenses of the packages in these areas and determine if they can distribute the packages on their CDs. Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages (such as our bug tracking system and mailing lists). - -1~ The Debian Free Software Guidelines (DFSG) - -2~ 1. Free Redistribution - -The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. - -2~ 2. Source Code - -The program must include source code, and must allow distribution in source code as well as compiled form. - -2~ 3. Derived Works - -The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. - -2~ 4. Integrity of The Author's Source Code - -The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.) - -2~ 5. No Discrimination Against Persons or Groups - -The license must not discriminate against any person or group of persons. - -2~ 6. No Discrimination Against Fields of Endeavor - -The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. - -2~ 7. Distribution of License - -The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. - -2~ 8. License Must Not Be Specific to Debian - -The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system. - -2~ 9. License Must Not Contaminate Other Software - -The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. - -2~ 10. Example Licenses - -The {"GPL"}http://www.debian.org/social_contract.1.0, {"BSD"}http://www.debian.org/misc/bsd.license, and {"Artistic"}http://www.perl.com/pub/a/language/misc/Artistic.html licenses are examples of licenses that we consider "free". - -/{The concept of stating our "social contract with the free software community" was suggested by Ean Schuessler. This document was drafted by Bruce Perens, refined by the other Debian developers during a month-long e-mail conference in June 1997, and then {accepted}http://lists.debian.org/debian-announce/debian-announce-1997/msg00017.html as the publicly stated policy of the Debian Project.}/ - -/{Bruce Perens later removed the Debian-specific references from the Debian Free Software Guidelines to create {"The Open Source Definition".}http://www.opensource.org/docs/definition.php }/ - -/{Other organizations may derive from and build on this document. Please give credit to the Debian project if you do.}/ - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~da.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~da.sst deleted file mode 100644 index e85b812c..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~da.sst +++ /dev/null @@ -1,142 +0,0 @@ -% SiSU 0.38 - -@title: Debians sociale kontrakt - -@subtitle: Debian Social Contract (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: Danish - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ).
"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1~dk.s3,v 1.2 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debians sociale kontrakt - -1~pre [Prefix]-# - -Version 1.1 blev vedtaget den 26. april 2004. Den erstattede version 1.0, som blev vedtaget den 5. juli 1997. - -Debian, der fremstiller Debian GNU/Linux-systemet, har skrevet Debians sociale kontrakt. Debians retningslinier for fri software (DFSG)-delen af kontrakten, oprindeligt et sæt løfter som vi er enige om at overholde, har fri software-fællesskabet taget til sig som basis for Open Source-definitionen (åben kildekode-definitionen). - -1~ Social kontrakt med fri software-fællesskabet - -2~ 1. Debian vil forblive 100 procent fri software - -De retningslinier vi bruger for at afgøre om et værk er "frit" stiller vi til rådighed i dokumentet "The Debian Free Software Guidelines", på dansk "Debians retningslinier for fri software". Vi lover at Debian-systemet og alle dets komponenter vil være frit tilgængelige jævnfør disse retningslinier. Vi vil støtte folk der udvikler og anvender både frie og ikke-frie værker på Debian. Vi vil aldrig lade systemet kræve anvendelse af et ikke-frit komponent. - -2~ 2. Vi vil give noget tilbage til fri software-fællesskabet - -Når vi udvikler nye komponenter til Debian-systemet, vil vi licensere dem på en måde som er i overensstemmelse med Debian retningslinier for fri software. Vi vil lave det bedste system vi kan, således at frit tilgængelige værker får stor udbredelse og anvendelse. Vi vil videregive ting så som fejlrettelser, forbedringer og brugerønsker til "opstrøms"-udviklerne af værker indeholdt i vores system. - -2~ 3. Vi vil ikke skjule problemer - -Hele vores database over fejlrapporter vil altid være åben for offentligheden. Rapporter som indsendes via Internet, vil med det samme kunne ses af andre. - -2~ 4. Vi prioriterer vore brugere og fri software højest - -Vi styres af brugernes og fri software-fællesskabets behov. Vi vil prioritere deres interesser højest. Vi vil understøtte vore brugeres behov for at kunne anvende mange forskellige computer-miljøer. Vi vil ikke gøre indsigelser mod ikke-frie værker der er beregnet til at køre på på Debian-systemer, eller forsøge at opkræve en afgift fra folk der udvikler eller anvender sådanne systemer. Vi vil tillade andre at fremstille distibutioner som indeholder både Debian-systemet og andre værker, uden at opkræve afgifter for det. For at fremme disse mål, vil vi stille et integreret system bestående af høj kvalitetsmateriale til rådighed, uden juridiske begrænsninger der kan forhindre sådanne anvendelser af systemet. - -2~ 5. Værker der ikke lever op til vore fri software-standarder - -Vi anerkender at nogle af vore brugere behøver programmer som ikke opfylder Debians retningslinier for fri software. Til det formål har vi oprettet områderne "contrib" (bidrag) og "non-free" (ikke-frit) i vores filarkiv. Pakkerne i disse områder udgør ikke en del af Debian-systemet, selvom de er opsat til brug sammen med Debian. Vi opfordrer cd-producenter til at læse licensbetingelser til pakkerne i disse områder og afgøre om de kan distribuere pakkerne på deres cd'er. Derfor, selvom ikke-frie værker ikke er en del af Debian, understøtter vi anvendelsen af dem og vi stiller infrastrukturen (som for eksempel vores fejlrapporteringssystem og postlister) til rådighed for ikke-frie pakker. - -1~ Debians retningslinier for fri software (DFSG) - -2~ 1. Fri videredistribution - -Et Debian-komponents licens må ikke forhindre nogen i at sælge eller forære programmet væk som en komponent i en samlet distribution, bestående af programmer fra flere forskellige kilder. Licensen må ikke kræve licenseringsafgifter eller lignende ved et sådant salg. - -2~ 2. Kildekode - -Programmet skal inkludere kildekode, og skal tillade distribution i form af både kildekode og et oversat program. - -2~ 3. Afledte værker - -Licensen skal tillade ændringer og afledte værker, og skal tillade at disse distribueres under de samme betingelser som det originale programs licens. - -2~ 4. Forfatterens kildekodes integritet - -Licensen må _kun_ begrænse distribuering af kildekoden i ændret form, hvis licensen tillader distribuering af "patch-filer" sammen med kildekoden med det formål at ændre programmet under oversættelse. Licensen skal eksplicit tillade distribution af programmer baseret på den ændrede kildekode. Licensen kan kræve at afledte værker har et andet navn eller versionsnummer end det originale program. (Dette er et kompromis. Debian-gruppen opfordrer alle forfattere til ikke at begrænse ændring af nogen filer, hverken kildekode eller oversat program.) - -2~ 5. Ingen diskrimination af personer eller grupper - -Licensen må ikke diskriminere nogen person eller gruppe af personer. - -2~ 6. Ingen diskrimination af anvendelsesområdet - -Licensen må ikke forhindre nogen i at bruge programmet indenfor et specifikt anvendelsesområde. Den må for eksempel ikke forhindre at programmet anvendes kommercielt eller i forbindelse med genetisk forskning. - -2~ 7. Distribution af licensen - -Rettighederne knyttet til programmet skal gælde alle, som programmet er videredistribueret til, uden at kræve yderligere licensering for disse parter. - -2~ 8. Licensen må ikke kun gælde Debian - -Rettighederne knyttet til programmet skal ikke være afhængig af at programmet er en del af Debian-systemet. Hvis programmet tages fra Debian og anvendes eller distribueres uden Debian, men ellers indenfor licensbetingelserne, skal alle parter som programmet er videredistribueret til, have de samme rettigheder som de licensbetingelser, der gives i forbindelse med Debian-systemet. - -2~ 9. Licensen må ikke smitte anden software - -Licensen må ikke lægge restriktioner på anden software som distribueres sammen med den licenserede software. For eksempel må licensen ikke insistere på, at alle andre programmer der distribueres på det samme medie er fri software. - -2~ 10. Eksempler på licenser - -"GPL"-, "BSD"-, og "Artistic"-licenserne er eksempler på licenser som vi betragter som værende "frie". - -Ean Schuessler foreslog at nedfælde vores "sociale kontrakt med fri software-fællesskabet". Det første udkast blev skrevet af Bruce Perens og blev fuldstændiggjort af de andre Debian-udviklere i løbet af en månedlang e-mail-konference i juni 1997, og dernæst accepteret som Debian-projektets offentlige retningslinier. - -Bruce Perens fjernede senere de Debian-specifikke referencer fra "Debians retningslinier for fri software", for at forfatte “Open Source-definitionen”. - -Andre organisationer må låne fra og basere sig på dette dokument. Angiv i givet fald venligst Debian-projektet som kilde. - -Tilbage til Debian-projektets hjemmeside. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~de.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~de.sst deleted file mode 100644 index 81edb455..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~de.sst +++ /dev/null @@ -1,142 +0,0 @@ -% SiSU 0.38 - -@title: Debian-Gesellschaftsvertrag - -@subtitle: Debian Social Contract (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: German - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.de.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.
"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.
Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich. - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1~de.s3,v 1.3 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debian-Gesellschaftsvertrag - -1~pre [Prefix]-# - -Dies ist die am 26. April 2004 ratifizierte Version 1.1. Sie ersetzt die am 5. Juli 1997 ratifizierte Version 1.0. - -Debian, die Hersteller des Systems Debian GNU/Linux, haben den »Gesellschaftsvertrag« aufgestellt. Die Debian-Richtlinien für Freie Software (DFSG), Teil dieses Vertrages und ursprünglich als eine Menge an Verpflichtungen entwickelt, denen wir zustimmen, wurden von der Free-Software-Community als Basis der Open-Source-Definition übernommen. - -1~ »Gesellschaftsvertrag« mit der Gemeinschaft für Freie Software - -2~ 1. Debian wird zu 100% frei bleiben - -Wir geben die Richtlinien, die wir verwenden, um zu bestimmen ob eine Arbeit »frei« ist, in dem »Die Debian-Richtlinien für Freie Software« genannten Dokument an. Wir versprechen, dass das Debian-System und alle dessen Komponenten entsprechend diesen Richtlinien frei sein werden. Wir werden Personen unterstützen, die freie und unfreie Arbeiten zu Debian erzeugen oder verwenden. Wir werden niemals das System von nicht-freien Komponenten abhängig machen. - -2~ 2. Unser Beitrag zur Gemeinschaft für Freie Software - -Wenn wir neue Komponenten des Debian-Systems schreiben, so werden wir sie auf eine Art lizenzieren, die in Einklang mit den Debian-Richtlinien für Freie Software steht. Wir werden das uns bestmögliche System erstellen, so dass Freie Arbeiten weit verbreitet und genutzt werden. Wir werden Dinge wie Korrekturen, Verbesserungen und Anwenderwünsche an die ursprünglichen (»upstream«) Autoren weiterleiten, deren Arbeiten in unser System integriert wurden. - -2~ 3. Wir werden Probleme nicht verbergen - -Wir werden unsere Fehlerdatenbank für alle Zeiten öffentlich betreiben. Fehlermeldungen, die von Personen online abgeschickt werden, werden unverzüglich für andere sichtbar. - -2~ 4. Unsere Prioritäten sind unsere Anwender und Freie Software - -Wir orientieren uns an den Bedürfnissen unserer Anwender und der Gemeinschaft für Freie Software. Deren Interessen stehen an erster Stelle. Wir werden unsere Nutzer bei ihrer Arbeit mit den verschiedensten Rechnerumgebungen unterstützen. Wir haben nichts gegen unfreie Arbeiten die darauf abzielen, auf Debian-Systemen verwendet zu werden, oder versuchen eine Gebühr von Personen, die solche Arbeiten erstellen oder verwenden, einzufordern. Wir erlauben anderen, Distributionen zu erstellen, die das Debian-System und andere Arbeiten enthalten, ohne dafür irgendwelche Gebühren zu erheben. Um diese Ziele zu fördern, werden wir ein integriertes System von hoher Qualität anbieten, das die gerade beschriebene Nutzung nicht durch rechtliche Einschränkungen verhindert. - -2~ 5. Arbeiten, die nicht unseren Standards für Freie Software genügen - -Wir wissen, dass einige unserer Anwender unbedingt Arbeiten einsetzen müssen, die nicht den Debian-Richtlinien für Freie Software entsprechen. Für solche Arbeiten haben wir die Bereiche »contrib« und »non-free« in unserem Archiv eingerichtet. Die Pakete in diesen Bereichen sind nicht Bestandteil des Debian-Systems, wurden aber trotzdem für den Einsatz mit Debian vorbereitet. Wir empfehlen den CD-Herstellern, die jeweiligen Lizenzbestimmungen der Pakete in diesen Bereichen zu studieren und selbst zu entscheiden, ob sie die Pakete mit ihren CDs verteilen dürfen. Obwohl unfreie Arbeiten nicht Bestandteil von Debian sind, unterstützen wir ihren Einsatz und bieten Infrastruktur für nicht freie Pakete an (z.B. unsere Fehlerdatenbank und die Mailinglisten). - -1~ Die Debian-Richtlinien für Freie Software (DFSG) - -2~ 1. Unbeschränkte Weitergabe - -Ein Bestandteil der Debian-Distribution darf durch seine Lizenz nicht verhindern, dass irgendjemand diese Software als Bestandteil einer Software-Distribution, die Programme aus den verschiedensten Quellen enthält, verkauft oder weitergibt. Die Lizenz darf keine Abgaben oder sonstige Leistungen für einen solchen Verkauf fordern. - -2~ 2. Quellcode - -Das Programm muss im Quellcode vorliegen, und es muss die Weitergabe sowohl im Quellcode als auch in kompilierter Form erlaubt sein. - -2~ 3. Weiterführende Arbeiten - -Die Lizenz muss Veränderungen und weiterführende Arbeiten gestatten und es erlauben, dass diese unter den gleichen Lizenzbedingungen weitergegeben werden dürfen wie die Original-Software. - -2~ 4. Integrität des ursprünglichen Quellcodes - -Die Lizenz darf die Weitergabe von verändertem Quellcode nur dann verbieten, wenn sie die Weitergabe von so genannten Patch-Dateien mit dem Quellcode erlaubt, die dazu dienen, das Programm vor seiner Herstellung zu modifizieren. Die Lizenz muss ausdrücklich die Weitergabe der aus dem veränderten Quellcode erzeugten Programme erlauben. Die Lizenz darf fordern, dass die veränderten Programme einen anderen Namen oder eine andere Versionsnummer tragen müssen. (Dies ist ein Kompromiss. Die Debian-Gruppe ermutigt alle Autoren, Veränderungen an Dateien sowohl im Quellcode als auch in Binärform zu erlauben.) - -2~ 5. Keine Diskriminierung von Personen oder Gruppen - -Die Lizenz darf keine Person oder Gruppe von Personen diskriminieren. - -2~ 6. Keine Diskriminierung von Einsatzbereichen - -Die Lizenz darf keine Einschränkungen hinsichtlich des Einsatzbereichs vornehmen. Beispielsweise darf sie nicht verhindern, dass das Programm geschäftlich oder für genetische Forschungen verwendet wird. - -2~ 7. Weitergabe der Lizenz - -Die mit einem Programm verbundenen Rechte müssen für alle gelten, die das Programm erhalten, ohne dass es für sie notwendig ist, eine zusätzliche Lizenz zu erwerben. - -2~ 8. Keine spezielle Lizenz für Debian - -Die mit dem Programm verbundenen Rechte dürfen nicht davon abhängig sein, dass das Programm Teil des Debian-Systems ist. Falls das Programm aus der Debian-Distribution herausgenommen wird und ohne Debian genutzt oder vertrieben werden soll, ansonsten aber im Rahmen der Programmlizenz bleibt, so müssen alle Parteien, die das Programm bekommen, die gleichen Rechte haben, wie sie im Zusammenhang mit dem Debian-System gewährt wurden. - -2~ 9. Keine Auswirkungen auf andere Programme - -Die Lizenz darf keine Beschränkungen besitzen, die Auswirkungen auf andere Software hat, die mit diesem Programm weitergegeben wird. Beispielsweise darf die Lizenz nicht vorschreiben, dass alle anderen Programme auf dem gleichen Medium Freie Software sein müssen. - -2~ 10. Beispiellizenzen - -Die »GPL«, »BSD« und »Artistic« Lizenzen sind Beispiele für Lizenzen, die wir als »frei« betrachten. - -Das Konzept, unseren »Gesellschaftsvertrag mit der Gemeinschaft für freie Software« aufzustellen, wurde von Ean Schuessler vorgeschlagen. Dieses Dokument wurde von Bruce Perens entworfen und von den anderen Debian-Entwicklern in einer einmonatigen E-Mail-Konferenz im Juni 1997 verfeinert, bevor es dann als öffentliche Richtlinie des Debian-Projekts akzeptiert wurde. - -Bruce Perens entfernte später die Debian-spezifischen Teile aus den Debian-Richtlinien für Freie Software um »Die Open-Source Definition« zu erstellen. - -Andere Organisationen können von diesem Dokument ableiten oder auf ihm aufbauen. Bitte erwähnen Sie das Debian-Projekt als Quelle, wenn Sie dies tun. - -Dies ist die deutsche Übersetzung von »Debian's social contract with the free software community«. In Zweifelsfällen ist das englische Original maßgeblich. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~es.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~es.sst deleted file mode 100644 index 71d33f0e..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~es.sst +++ /dev/null @@ -1,140 +0,0 @@ -% SiSU 0.38 - -@title: Contrato social de Debian - -@subtitle: Debian Social Contract (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: Spanish - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.es.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
OJO: Esta es una traducción de la licencia original, y no tiene ningún valor jurídico http://www.debian.org/license.en.html. Si desea ver la versión verdadera debe acudir a la licencia original, en este mismo servidor.
Este material sólo puede ser distribuido sujeto a los términos y condiciones indicados en la Licencia de publicaciones abiertas, borrador v1.0 o posterior (puede consultar nuestra copia local http://www.debian.org/opl ; la última versión suele estar disponible en http://www.opencontent.org/openpub/ ).
"Debian" y el logotipo de Debian http://www.debian.org/logos/ son marcas registradas de Software in the Public Interest, Inc. - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1~es.s3,v 1.2 2006/02/28 12:11:55 ralph Exp $ - -:A~ Contrato social de Debian - -1~pre [Prefix]-# - -La versión 1.1 ratificada el 26 de abril de 2004 deroga la versión 1.0 ratificada el 5 de julio de 1997. - -El proyecto Debian, creador del sistema Debian GNU/Linux, ha creado el contrato social de Debian. Este documento es una declaración de intenciones por nuestra parte y un conjunto de principios que acatamos. La parte del contrato llamada directrices de software libre de Debian (Debian Free Software Guidelines, DFSG)— diseñada inicialmente como un un conjunto de criterios para definir lo que es software libre—, ha sido adoptada posteriormente por la comunidad de software libre como base para la definición de Open Source. - -1~ «Contrato social» con la comunidad de software libre - -2~ 1. Debian permanecerá 100% libre - -Las «Las directrices de software libre de Debian» (DFSG) son el criterio que nosotros utilizamos para determinar si el software es «libre» o no. Prometemos mantener el sistema GNU/Linux así como todos sus componentes completamente libres de acuerdo con este criterio. No obstante, daremos soporte también a aquellos usuarios que desarrollen y ejecuten software no libre en Debian pero nunca haremos que el sistema tenga que utilizar obligatoriamente un componente que no sea libre. - -2~ 2. Contribuiremos a la comunidad de software libre - -Cuando escribamos nuevos componentes del sistema Debian, los licenciaremos de forma consistente con nuestra definición de software libre. Haremos el mejor sistema que podamos, de forma que el software libre tenga amplia difusión y uso. Enviaremos parches, mejoras, peticiones de los usuarios, etc a los autores originales (esto se conoce en inglés como upstream, N. del T.) del software incluido en nuestro sistema. - -2~ 3. No ocultaremos los problemas - -Mantendremos nuestra base de datos de informes de error accesible al público en todo momento. Los informes de error que los usuarios envíen serán visibles por el resto de usuarios de forma inmediata. - -2~ 4. Nuestra prioridad son nuestros usuarios y el software libre - -Nos guiaremos por las necesidades de nuestros usuarios y de la comunidad del software libre. Sus intereses serán una prioridad para nosotros. Daremos soporte a las necesidades de nuestros usuarios para que puedan trabajar en muchos tipos distintos de entornos de trabajo. No pondremos objeciones al software no libre que vaya a ejecutarse sobre Debian ni cobraremos a las personas que quieran desarrollar o usar ese tipo de software (no libre). Permitiremos a otros crear distribuciones de valor añadido basadas en Debian sin cobrarles nada por ello. Es más, entregaremos un sistema integrado de alta calidad sin restricciones legales que pudieran prevenir este tipo de uso. - -2~ 5. Trabajos que no siguen nuestros estándares de software libre - -Reconocemos que algunos de nuestros usuarios necesitan usar trabajos que no sigan las directrices de software libre de Debian (DFSG). Por ello, hemos creado las secciones «contrib» y «non-free» en nuestro archivo para estos trabajos. Los paquetes en estas secciones no son parte del sistema Debian, aunque ha sido configurado para usarse con Debian. Animamos a los distribuidores de CDs a que lean las licencias de los paquetes en estas secciones para poder determinar si pueden distribuir este software en sus CDs. Así pues, aunque los trabajos que no sean libres no son parte de Debian, damos soporte para su uso, y proporcionamos infraestructuras (como nuestro sistema de informe de errores y listas de distribución) para paquetes no libres. - -1~ Las directrices de software libre de Debian (DFSG) - -2~ 1. Libre redistribución - -La licencia de un componente de Debian no puede restringir a un tercero el vender o entregar el programa como parte de una distribución mayor que contiene programas de diferentes fuentes. La licencia no debe solicitar «royalties» u otras comisiones para esta venta. - -2~ 2. Código fuente - -El programa debe incluir el código fuente completo, y debe permitir la distribución en forma de código fuente y en forma compilada (binario). - -2~ 3. Trabajos derivados - -La licencia debe permitir modificaciones y trabajos derivados y debe permitir que estos se distribuyan bajo los mismos términos que la licencia del programa original. - -2~ 4. Integridad del código fuente del autor - -La licencia puede restringir la distribución del código fuente en forma modificada *sólo* si la licencia permite la distribución de «parches» («patch files») para poder modificar el código fuente original del programa en el momento de compilarlo. La licencia debe permitir explícitamente la distribución de software a partir de código fuente modificado. La licencia puede obligar a los trabajos derivados a llevar un nombre o número de versión diferentes del programa original (Esto es un compromiso. El grupo de Debian anima a todos los autores a no restringir ningún fichero, fuente o compilado, de ser modificado.) - -2~ 5. No discriminación contra personas o grupos - -La licencia no debe discriminar a ninguna persona o grupo de personas. - -2~ 6. No discriminación en función de la finalidad perseguida - -La licencia no puede restringir el uso del programa para una finalidad determinada. Por ejemplo, no puede restringir el uso del programa a empresas con fines comerciales, o en investigación genética. - -2~ 7. Distribución de la licencia - -Los derechos y libertades de uso asociados al programa deben aplicarse en la misma forma a todos aquellos a los que se redistribuya el programa, sin necesidad de pedir una licencia adicional para estas terceras partes. - -2~ 8. La licencia no ha de ser específica para Debian - -Los derechos asociados al programa no deben depender de que el programa sea parte o no del sistema Debian. Si el programa es extraído de Debian y usado o distribuido sin Debian, pero manteniendo el resto de las condiciones de la licencia, todos aquellos a los que el programa se redistribuya deben tener los mismos derechos que los dados cuando forma parte de Debian. - -2~ 9. La licencia no debe contaminar a otros programas - -La licencia no debe poner restricciones sobre otros programas que se distribuyan junto con el programa licenciado. Por ejemplo, la licencia no puede insistir que todos los demás programas distribuidos sobre el mismo medio deben ser software libre. - -2~ 10. Ejemplos de licencias - -Las licencias «GPL», «BSD», y « Artística» son ejemplos de licencias que nosotros consideramos «libres». - -La expresión «contrato social con la comunidad de software libre» fue sugerida por Ean Schuessler. El primer borrador de este documento fue escrito por Bruce Perens, fue modificado por los demás desarrolladores de Debian durante una conferencia por correo electrónico que duró un mes (junio de 1997) y finalmente aceptado como la normativa pública del proyecto Debian. - -Posteriormente, Bruce Perens eliminó las referencias específicas a Debian en las directrices de Debian para el Software Libre (DFSG), creando “la definición de Open Source”. - -Cualquier otra organización puede llevar a cabo trabajos derivados a partir de este documento. Por favor, haga referencia al proyecto Debian en tal caso. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fi.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fi.sst deleted file mode 100644 index 232fadd7..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fi.sst +++ /dev/null @@ -1,142 +0,0 @@ -% SiSU 0.38 - -@title: Debianin yhteisösopimus - -@subtitle: Debian Social Contract (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: Finnish - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.fi.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Tätä materiaalia voidaan levittää ainoastaan Open Publication License, vedos v1.0 (paikallinen kopiomme luettavaksesi http://www.debian.org/opl ) tai myöhemmän määräysten ja ehtojen mukaisesti. Uusin versio on saatavilla yleensä osoitteesta http://www.opencontent.org/.
"Debian" ja Debian-logo http://www.debian.org/logos/ ovat Software in the Public Interest, Inc.:n tavaramerkkejä.
http://www.debian.org/license.en.html - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1~fi.s3,v 1.2 2006/02/28 12:11:55 ralph Exp $ - -:A~ Debianin yhteisösopimus - -1~pre [Prefix]-# - -Versio 1.1 ratifioitiin 26. huhtikuuta 2004. Se korvaa version 1.0, joka ratifioitiin 5. heinäkuuta 1997. - -Debian, joka koostuu Debian GNU/Linux -järjestelmän tekijöistä, on luonut Debianin yhteisösopimuksen. Sen osan sopimuksesta, joka tunnetaan nimellä Debianin vapaiden ohjelmistojen ohjeisto (Debian Free Software Guidelines (DFSG)) ja jonka oli alun perin tarkoitus määrittää joukko sitoumuksia, jotka aiomme pitää, on vapaiden ohjelmistojen yhteisö ottanut Open Source -määritelmän pohjaksi. - -1~ Yhteisösopimus vapaiden ohjelmistojen yhteisön kanssa - -2~ 1. Debian pysyy täysin vapaana - -Olemme luoneet ohjeiston nimeltään Debianin vapaiden ohjelmistojen ohjeisto (Debian Free Software Guidelines, DFSG), jonka perusteella määrittelemme milloin jokin teos on vapaa. Lupaamme, että Debian-järjestelmä kaikkine osineen on vapaa kyseisen ohjeiston määrittelemässä mielessä. Tuemme ihmisiä, jotka luovat tai käyttävät sekä vapaita että epävapaita teoksia Debian-järjestelmässä. Emme koskaan muuta järjestelmää sellaiseksi, että se edellyttäisi epävapaiden osien käyttämistä. - -2~ 2. Annamme takaisin vapaiden ohjelmistojen yhteisölle - -Kun teemme Debian-järjestelmään uusia osia, lisensoimme ne Debianin vapaiden ohjelmistojen ohjeiston mukaisesti. Teemme niin hyvän järjestelmän kuin suinkin pystymme, jotta vapaita teoksia levitettäisiin ja käytettäisiin laajalti. Välitämme korjaukset, parannukset ja käyttäjien toiveet "ylävirtaan" eli järjestelmäämme sisältyvien teosten tekijöille. - -2~ 3. Emme kätke ongelmia - -Pidämme vikailmoitustietokantamme jatkuvasti kaikkien nähtävillä. Sähköisesti toimitetut vikailmoitukset tulevat ripeästi muiden nähtäville. - -2~ 4. Käyttäjämme ja vapaat ohjelmistot ovat tärkeimmät prioriteettimme - -Käyttäjiemme ja vapaiden ohjelmistojen yhteisön tarpeet ohjaavat meitä, ja asetamme nämä tarpeet ensimmäiselle sijalle. Tuemme käyttäjiemme tarpeita monenlaisissa tietojenkäsittely-ympäristöissä. Emme vastusta Debian-järjestelmissä käytettäväksi tarkoitettuja epävapaita teoksia emmekä yritä periä maksua henkilöiltä, jotka luovat tai käyttävät sellaisia teoksia. Sallimme muiden luoda ilman maksua käyttöjärjestelmäjakeluita, joihin sisältyy sekä Debian-järjestelmä että muita teoksia. Näiden tavoitteiden edistämiseksi tarjoamme korkealaatuisista, keskenään hyvin toimivista osista muodostuvan järjestelmän ilman mitään lakiin perustuvia rajoituksia, jotka voisivat estää edellä kuvatun mukaisen käytön. - -2~ 5. Teokset, jotka eivät täytä vapaiden ohjelmistojen vaatimuksiamme - -Tiedostamme, että joidenkin käyttäjiemme on välttämätöntä käyttää teoksia, jotka eivät vastaa Debianin vapaiden ohjelmistojen ohjeiston vaatimuksia. Tällaisia teoksia varten olemme luoneet tiedostoarkistoomme "contrib"- ja "non-free"-osiot. Näihin osioihin kuuluvat paketit eivät ole osa Debian-järjestelmää, vaikka ne onkin mukautettu toimimaan Debianissa. Kannustamme CD-valmistajia lukemaan näissä osioissa olevien pakettien lisenssiehdot ja selvittämään, voivatko he levittää kyseisiä paketteja CD-levyillään. Näin ollen, vaikka epävapaat teokset eivät kuulu Debianiin, tuemme niiden käyttöä ja tarjoamme epävapaiden pakettien tueksi infrastruktuurin (kuten vianseurantajärjestelmän ja sähköpostilistat). - -1~ Debianin vapaiden ohjelmistojen ohjeisto (DFSG) - -2~ 1. Vapaa levitys - -Debianin osan levitysehdot eivät saa rajoittaa ketään myymästä tai antamasta kyseistä ohjelmistoa osana ohjelmistokokoelmaa, joka sisältää eri lähteistä saatuja ohjelmia. Nämä levitysehdot eivät saa vaatia myyjältä rojalteja tai muita maksuja. - -2~ 2. Lähdekoodi - -Ohjelman mukana tulee olla sen lähdekoodi, ja pitää olla sallittua levittää ohjelmaa lähdekielisenä kohdekielisen lisäksi. - -2~ 3. Johdannaisteokset - -Ohjelman levitysehtojen tulee sallia muutoksien ja johdannaisteosten tekeminen ja myös sallia näiden levittäminen samoin ehdoin kuin alkuperäisen ohjelman. - -2~ 4. Alkuperäisen lähdekoodin eheys - -Ohjelman levitysehdot saavat rajoittaa muutetun lähdekoodin levitystä _vain_, jos se sallii "muutostiedostojen" (patch files) levityksen lähdekoodin kanssa tarkoituksena muuttaa ohjelmaa käännösaikana. Levitysehtojen tulee erityisesti sallia muutetusta lähdekoodista tuotetun ohjelman levittäminen. Ne saavat vaatia, että johdannaisteoksien nimenä tai versionumerona käytetään jotain muuta kuin alkuperäisen ohjelman nimeä tai versionumeroa. (Tämä on kompromissi. Debian suosittelee kaikille ohjelmien tekijöille pidättäytymistä minkäänlaisten tiedostojen, lähde- tai kohdekielisten, muuttamisen kieltämisestä.) - -2~ 5. Ei ihmisten tai ihmisryhmien syrjintää - -Ohjelman levitysehdot eivät saa syrjiä ketään ihmistä tai mitään ihmisryhmää. - -2~ 6. Ei toiminnan alojen syrjintää - -Ohjelman levitysehdot eivät saa estää ketään käyttämästä ohjelmaa tietyllä alalla. Esimerkiksi ohjelman käyttöä yrityksessä ei saa rajoittaa, tai sen käyttöä geenitutkimuksessa. - -2~ 7. Levitysehtojen jatkuvuus - -Ohjelmaan liittyvien oikeuksien tulee koskea kaikkia, jotka ovat hankkineet ohjelmasta kappaleen ilman, että heidän tarvitsee hankkia erillinen lisenssi. - -2~ 8. Levityslupa ei saa olla vain Debianille - -Ohjelmaan liittyvät oikeudet eivät saa riippua ohjelman olemisesta osa Debiania. Jos ohjelma irrotetaan Debianista ja sitä käytetään tai levitetään ilman Debiania mutta muuten levitysehtojen mukaisesti, kaikilla osapuolilla tulee olla samat oikeudet, jotka annetaan Debian-järjestelmän yhteydessä. - -2~ 9. Levitysehdot eivät saa saastuttaa muita ohjelmia - -Ohjelman levitysehdot eivät saa asettaa rajoituksia muille ohjelmille, jotka levitetään kyseisen ohjelman kanssa. Ehdot eivät saa esimerkiksi vaatia, että muiden samalla levitysmedialla olevien ohjelmien tulee olla vapaita. - -2~ 10. Esimerkkilisenssejä - -"GPL", "BSD" ja "Artistic"-lisenssit ovat esimerkkejä lisensseistä, jotka ovat mielestämme "vapaita". - -Ean Schuessler ehdotti ajatusta tuoda julki "yhteiskunnallinen sopimuksemme vapaiden ohjelmistojen yhteisön kanssa". Bruce Perens kirjoitti tämän asiakirjan ensimmäisen luonnoksen ja paranteli sitä Debian-kehittäjien kommenttien perusteella kuukauden pituisen sähköpostikonferenssin aikana kesäkuussa 1997, ja joka sitten hyväksyttiin julkisesti esitettäväksi Debian-projektin linjaksi. - -Bruce Perens poisti myöhemmin Debian-spesifiset viittaukset Debianin vapaiden ohjelmien ohjeistosta luodakseen “Open Source -määritelmän”. - -Muut yhteisöt saavat luoda johdannaisia tästä asiakirjasta. Toivomme, että tunnustatte Debian-projektin roolin asiakirjan luomisessa, jos näin teette. - -Takaisin Debian-projektin kotisivulle. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fr.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fr.sst deleted file mode 100644 index d1648747..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~fr.sst +++ /dev/null @@ -1,140 +0,0 @@ -% SiSU 0.38 - -@title: Le contrat social Debian - -@subtitle: Debian Social Contract (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: French - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% @italics: - -@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Ce matériel ne peut être distribué que conformément aux termes et conditions présentés dans la Licence de Publication Ouverte (Open Publication License), Draft v.1.0 ou suivantes. (Vous pouvez lire notre copie locale http://www.debian.org/opl, dont la version la plus récente est généralement disponible à http://www.opencontent.org/ ).
« Debian » et le logo Debian sont des marques déposées appartenant à Software in the Public Interest, Inc.
En cas de litige, seule la version originale de cette page a valeur au regard de la loi http://www.debian.org/license.en.html. - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1~fr.s3,v 1.2 2006/02/28 12:11:55 ralph Exp $ - -:A~ Le contrat social Debian - -1~pre [Prefix]-# - -Version 1.1 ratifiée le 26 avril 2004. Remplace la version 1.0 ratifiée le 5 juillet 1997. - -Le projet Debian, concepteur du système GNU/Linux Debian, a créé le contrat social de Debian. La partie consacrée aux principes du logiciel libre selon Debian (Debian Free Software Guidelines, ou DFSG), initialement conçue comme un ensemble de principes auxquels nous tenons fermement, a été adoptée par la communauté du logiciel libre comme base pour la définition de l'informatique libre (Open Source Definition). - -1~ « Contrat social » avec la communauté des logiciels libres - -2~ 1. Debian demeurera totalement libre. - -Nous fournissons les principes que nous utilisons pour déterminer si un travail est « libre » dans le document intitulé « Principes du logiciel libre selon Debian ». Nous promettons que le système Debian et tous ses composants seront libres selon ces principes. Nous aiderons les personnes qui créent et utilisent à la fois des travaux libres et non libres sur Debian. Nous ne rendrons pas le système dépendant d'un composant non libre. - -2~ 2. Nous donnerons nos travaux à la communauté des logiciels libres. - -Lorsque nous écrirons de nouveaux composants du système Debian, nous les publierons sous une licence compatible avec les principes du logiciel libre selon Debian. Nous ferons le meilleur système possible, afin que les travaux libres soient largement distribués et utilisés. Nous signalerons les corrections de bogues, les améliorations, les requêtes des utilisateurs, etc. aux auteurs des travaux originels inclus dans notre système. - -2~ 3. Nous ne cacherons pas les problèmes. - -Toute notre base de données sur les rapports de bogue sera consultable à tous moments par tous. Les rapports que les personnes remplissent en ligne seront immédiatement visibles par les autres. - -2~ 4. Nos priorités sont nos utilisateurs et les logiciels libres. - -Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. Nous assumerons les besoins de nos utilisateurs dans de nombreux types d'environnements informatiques différents. Nous ne nous opposerons pas aux travaux non libres prévus pour fonctionner sur les systèmes Debian. Nous permettrons que d'autres créent des distributions contenant conjointement des logiciels Debian et d'autres travaux, et ceci sans réclamer aucune rétribution. Pour servir ces objectifs, nous fournirons un système intégré de composants de grande qualité sans restrictions légales qui empêcheraient ces types d'usage. - -2~ 5. Travaux non conformes à nos standards sur les logiciels libres. - -Nous reconnaissons que certains de nos utilisateurs demandent à pouvoir utiliser des travaux qui ne sont pas conformes aux principes du logiciel libre selon Debian. Pour ces travaux, nous avons créé des sections contrib (« contributions ») et non-free (« non libre ») dans notre archive. Les paquets dans ces sections ne font pas partie du système Debian, bien qu'ils aient été configurés afin d'être utilisés avec Debian. Nous encourageons les fabricants de CD à lire les licences des paquets en question afin de déterminer s'ils peuvent les distribuer dans leurs CD. Ainsi, bien que les travaux non libres ne fassent pas partie de Debian, nous assumons leur utilisation et fournissons une infrastructure (à l'image de notre système de suivi des bogues et de nos listes de diffusion) pour des paquets non libres. - -1~ Les principes du logiciel libre selon Debian - -2~ 1. Redistribution libre et gratuite. - -La licence d'un composant de Debian ne doit pas empêcher quiconque de vendre ou donner le logiciel sous forme de composant d'un ensemble (distribution) constitué de programmes provenant de différentes sources. La licence ne doit requérir ni redevance ni rétribution sur une telle vente. - -2~ 2. Code source. - -Le programme doit inclure le code source, et la diffusion sous forme de code source comme sous forme de programme compilé doit être autorisée. - -2~ 3. Applications dérivées. - -La licence doit permettre les modifications et les applications dérivées, et elle doit permettre à celles-ci d'être distribuées sous les mêmes termes que ceux de la licence du logiciel original. - -2~ 4. Intégrité du code source de l'auteur. - -La licence peut défendre de distribuer le code source modifié seulement si elle autorise la distribution avec le code source de fichiers correctifs destinés à modifier le programme au moment de la construction. La licence doit autoriser explicitement la distribution de logiciels créés à partir de code source modifié. Elle peut exiger que les applications dérivées portent un nom ou un numéro de version différent de ceux du logiciel original (c'est un compromis ; le groupe Debian encourage tous les auteurs à ne restreindre en aucune manière les modifications des fichiers, source ou binaire). - -2~ 5. Aucune discrimination de personne ou de groupe. - -La licence ne doit discriminer aucune personne ou groupe de personnes. - -2~ 6. Aucune discrimination de champ d'application. - -La licence ne doit pas défendre d'utiliser le logiciel dans un champ d'application particulier. Par exemple, elle ne doit pas défendre l'utilisation du logiciel dans une entreprise ou pour la recherche génétique. - -2~ 7. Distribution de licence. - -Les droits attachés au programme doivent s'appliquer à tous ceux à qui il est distribué sans obligation pour aucune de ces parties de se conformer à une autre licence. - -2~ 8. La licence ne doit pas être spécifique à Debian. - -Les droits attachés au programme ne doivent pas dépendre du fait qu'il fasse partie du système Debian. Si le programme est extrait de Debian et est utilisé et distribué sans Debian mais sous les termes de sa propre licence, toutes les parties auxquelles il est redistribué doivent jouir des même droits que ceux accordés avec le système Debian. - -2~ 9. La licence ne doit pas contaminer d'autres logiciels. - -La licence ne doit pas placer de restrictions sur d'autres logiciels distribués avec le logiciel licencié. Par exemple, la licence ne doit pas exiger que tous les autres programmes distribués sur le même support doivent être des logiciels libres. - -2~ 10. Exemples de licence. - -Les licences « GPL », « BSD » et « Artistic » sont des exemples de licences que nous considérons « libres ». - -L'idée de rédiger nos « principes du logiciel libre » fut suggérée par Ean Schuessler. Bruce Perens écrivit la première ébauche de ce document et le perfectionna d'après les commentaires des développeurs de Debian recueillis à l'occasion d'une conférence par courriels qui s'est déroulé pendant tout le mois de juin 1997. Il fut ensuite accepté comme faisant partie intégrante de la charte du projet Debian. - -Plus tard, Bruce Perens retira toute référence au projet Debian des DFSG pour en faire la « Définition de l'Open Source ». - -D'autres organisations peuvent utiliser ce document. Si vous le faites, veuillez faire référence au projet Debian. - -%% SiSU markup sample Notes: -% SiSU http://www.jus.uio.no/sisu -% SiSU markup for 0.16 and later: -% 0.20.4 header 0~links -% 0.22 may drop image dimensions (rmagick) -% 0.23 utf-8 ß -% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) -% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 -% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html -% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~it.sst b/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~it.sst deleted file mode 100644 index 666862ff..00000000 --- a/debian/data/sisu_markup_samples/dfsg/debian_social_contract_v1.1~it.sst +++ /dev/null @@ -1,132 +0,0 @@ -% SiSU 0.38 - -@title: Contrato social de Debian - -@subtitle: Debian Social Contract (v1.1) - -@creator: Debian Project - -@type: information - -@subject: debian policy - -@date.created: 1997-07-05 - -@date.issued: 1997-07-05 - -@date.valid: 2004-04-26 - -@date.available: 2004-04-26 - -@date.modified: 2004-04-26 - -@date: 2004-04-26 - -@language.document: Italian - -@language.original: English - -@level: new=C; num_top=1 - -@skin: skin_debian - -@bold: Debian; DPL - -% 0~italics - -@rights: http://www.debian.org/license.it.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/
Questo materiale può essere distribuito solo ai termini e sotto le consizioni poste nel “Open Publication License”, Bozza v1.0 o successiva (si può leggere la nostra copia http://www.debian.org/opl o l’ultima versione normalmente disponibile presso http://www.opencontent.org/openpub/ ).
“Debian” e il Logo Debian http://www.debian.org/logos/ sono trademark di Software in the Public Interest, Inc.
N.d.T.: Questa è una traduzione della licenza originale in inglese. In tutti in casi in cui il significato della traduzione differisca da quello dell’originale, la versione corretta è da considerarsi quella originale http://www.debian.org/license.en.html. - -@links: {Authoritative Source Document}http://www.debian.org/social_contract -{Debian Constitution @ SiSU}http://www.jus.uio.no/sisu/debian_constitution_v1.3/sisu_manifest.html -{About Debian}http://www.debian.org/intro/about -{News}http://www.debian.org/News/ -{Getting Debian}http://www.debian.org/distrib/ -{Support}http://www.debian.org/support -{Developer's Corner}http://www.debian.org/devel/ -{Sitemap}http://www.debian.org/sitemap -{Search}http://search.debian.org/ - -@prefix: This is taken from the authoritative source at http://www.debian.org/social_contract and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original. - -@rcs: $Id: debian_social_contract_v1.1~es.sst,v 1.1 2006/03/05 14:54:51 ralph Exp $ - -:A~ Il Contratto Sociale Debian - -1~pre [Prefix]-# - -La versione 1.1 approvata il 26 aprile 2004 che sostituisce la versione 1.0 approvata il 5 luglio 1997. - -Debian, i produttori del sistema Debian GNU/Linux, ha creato il Contratto Sociale Debian (Debian Social Contract). Le Linee Guida Debian per il Software Libero (Debian Free Software Guidelines - DFSG) che sono parte del contratto, inizialmente pensate come un insieme di punti che noi tutti sottoscriviamo, sono state adottate dalla comunità del software libero come base per l'Open Source Definition. - -1~ Contratto Sociale con la Comunità Free Software - -2~ 1. Debian rimarrà libera al 100% - -Forniamo le linee guida che usiamo per determinare se un'opera sia "libera" nel documento intitolato "The Debian Free Software Guidelines". Promettiamo che il sistema Debian e tutte le sue componenti rimarranno liberi in accordo con le citate linee guida. Supporteremo le persone che creino o usino in Debian opere sia libere che non libere. Non renderemo mai il sistema dipendente da un componente non libero. - -2~ 2. Renderemo alla Comunità Free Software - -Quando scriviamo nuovi componenti del sistema Debian, li rilasceremo con una licenza che rispetti le Debian Free Software Guidelines. Realizzeremo il sistema migliore che potremo, cosicché le opere libere siano usate e distribuite il più possibile. Comunicheremo cose come bug fix, migliorie e richieste degli utenti agli autori "upstream" delle opere incluse nel nostro sistema. - -2~ 3. Non nasconderemo i problemi - -Manterremo sempre il nostro intero bug report database aperto alla pubblica lettura. I rapporti che le persone invieranno online saranno prontamente resi visibili a tutti. - -2~ 4. Le nostre priorità sono gli utenti ed il software libero - -Ci faremo guidare dai bisogni dei nostri utenti e della comunità del software libero. Metteremo al primo posto i loro interessi. Supporteremo le necessità dei nostri utenti di operare in molti diversi tipi di ambienti di calcolo. Non ci opporremo alle opere non libere che siano state pensate per l'uso in sistemi Debian e non richiederemo compensi a chi crea o usa queste opere. Permetteremo ad altri di creare distribuzioni contenenti sia il sistema Debian che altre opere, senza richiedere compensi. Per raggiungere questi scopi, forniremo un sistema integrato di materiali di alta qualità senza alcuna restrizione legale che limiti qualsiasi uso del sistema. - -2~ 5. Opere che non rispettano i nostri standard free software - -Ci rendiamo conto che alcuni dei nostri utenti richiedono di usare opere non conformi alle Debian Free Software Guidelines. Abbiamo creato le aree "contrib" e "non-free" nel nostro archivi per queste opere. I pacchetti in queste aree non fanno parte del sistema Debian, sebbene siano stati configurati per l'uso con Debian. Invitiamo i realizzatori di CD a leggere le licenze dei pacchetti in queste aree per determinare se possono distribuire i pacchetti sui loro CD. Inoltre, anche se le opere non libere non fanno parte di Debian, supporteremo il loro uso e forniremo infrastrutture per i pacchetti non liberi (come il nostro bug tracking system e le mailing list). - -1~ Le Linee Guida Debian per il Software Libero (Debian Free Software Guidelines - DFSG) - -2~ 1. Libera ridistribuzione - -La licenza di un componente Debian non può porre restrizioni a nessuno per la vendita o la cessione del software come componente di una distribuzione software aggregata di programmi proveniente da fonti diverse. La licenza non può richiedere royalty o altri pagamenti per la vendita. - -2~ 2. Codice sorgente - -Il programma deve includere il codice sorgente e deve permettere la distribuzione sia come codice sorgente che in forma compilata. - -2~ 3. Lavori derivati - -La licenza deve permettere modifiche e lavori derivati e deve permettere la loro distribuzione con i medesimi termini della licenza del software originale. - -2~ 4. Integrità del codice sorgente dell'autore - -La licenza può porre restrizioni sulla distribuzione di codice sorgente modificato _solo_ se permette la distribuzione di "file patch" insieme al codice sorgente con lo scopo di modificare il programma durante la compilazione. La licenza deve esplicitamente permettere la distribuzione di software compilato con codice sorgente modificato. La licenza può richiedere che i lavori derivati abbiano un nome o un numero di versione diversi da quelli del software originali. (Questo è un compromesso. Il gruppo Debian invita tutti gli autori a non impedire che file, sorgenti o binari possano essere modificati.) - -2~ 5. Nessuna discriminazione di persone o gruppi - -La licenza non può discriminare nessuna persona o gruppo di persone. - -2~ 6. Nessuna discriminazione nei campi di impiego - -La licenza non può porre restrizioni all'utilizzo del programma in uno specifico campo di impiego. Per esempio, non può porre restrizioni all'uso commerciale o nella ricerca genetica. - -2~ 7. Distribuzione della licenza - -I diritti applicati al programma devono essere applicabili a chiunque riceva il programma senza il bisogno di utilizzare licenze addizionali di terze parti. - -2~ 8. La licenza non può essere specifica per Debian - -I diritti applicati al programma non possono dipendere dal fatto che esso sia parte di un sistema Debian. Se il programma è estratto da Debian e usato o distribuito senza Debian ma ottemperando ai termini della licenza, tutte le parti alle quali il programma è ridistribuito dovrebbero avere gli stessi diritti di coloro che lo ricevono con il sistema Debian. - -2~ 9. La licenza non deve contaminare altro software - -La licenza non può porre restrizioni ad altro software che sia distribuito insieme al software concesso in licenza. Per esempio, la licenza non può richiedere che tutti gli altri programmi distribuiti con lo stesso supporto debbano essere software libero. - -2~ 10. Esempi di licenze - -Le licenze "GPL", "BSD" e "Artistic" sono esempi di licenze che consideriamo "libere". - -I concetti enunciati nel nostro "contratto sociale con la comunità del software libero" furono proposti da Ean Schuessler. Questo documento fu abbozzato da Bruce Perens, rifinito da altri sviluppatori Debian durante una conferenza via posta elettronica durata un mese (Giugno 1997) ed infine approvata come pubblica linea di condotta del Progetto Debian. - -Bruce Perens in seguito ha rimosso i riferimenti specifici a Debian dalle Linee Guida Debian per il Free Software per creare “L'Open Source Definition”. - -Altre organizzazioni possono derivare da questo documento. Per favore, se lo si fa, se ne dia credito al progetto Debian. - -Ritorna alla pagina principale del Progetto Debian. - -- cgit v1.2.3