ANEXOS

ANEXO I

1.1 - LICENÇA PROPRIETÁRIA - EULA

Copiada no dia 05/05/2005 às 9:18 hs Disponível no site: http://www.microsoft.com/windowsxp/pro/eula.mspx

Microsoft Windows XP Professional END-USER LICENSE AGREEMENT This End-User License Agreement (EULA) is for informational purposes only. There is no software accompanying the EULA.

IMPORTANT—READ CAREFULLY: This End-User License Agreement ("EULA") is a legal agreement between you (either an individual or a single entity) and Microsoft Corporation for the Microsoft software product identified above, which includes computer software and may include associated media, printed materials, "online" or electronic documentation, and Internet-based services ("Product"). An amendment or addendum to this EULA may accompany the Product. YOU AGREE TO BE BOUND BY THE TERMS OF THIS EULA BY INSTALLING, COPYING, OR OTHERWISE USING THE PRODUCT. IF YOU DO NOT AGREE, DO NOT INSTALL OR USE THE PRODUCT; YOU MAY RETURN IT TO YOUR PLACE OF PURCHASE FOR A FULL REFUND. 1. GRANT OF LICENSE. Microsoft grants you the following rights provided that you comply with all terms and conditions of this EULA: • Installation and use. You may install, use, access, display and run one copy of the Product on a single computer, such as a workstation, terminal or other device ("Workstation Computer"). The Product may not be used by more than two (2) processors at any one time on any single Workstation Computer. You may permit a maximum of ten (10) computers or other electronic devices (each a "Device") to connect to the Workstation Computer to utilize the services of the Product solely for File and Print services, Internet Information Services, and remote access (including connection sharing and telephony services). The ten connection maximum includes any indirect connections made through "multiplexing" or other software or hardware which pools or aggregates connections. Except as otherwise permitted by the NetMeeting?, Remote Assistance, and Remote Desktop features described below, you may not use the Product to permit any Device to use, access, display or run other executable software residing on the Workstation Computer, nor may you permit any Device to use, access, display, or run the Product or Product's user interface, unless the Device has a separate license for the Product. • Mandatory Activation.The license rights granted under this EULA are limited to the first thirty (30) days after you first install the Product unless you supply information required to activate your licensed copy in the manner described during the setup sequence of the Product. You can activate the Product through the use of the Internet or telephone; toll charges may apply. You may also need to reactivate the Product if you modify your computer hardware or alter the Product. There are technological measures in this Product that are designed to prevent unlicensed or illegal use of the Product. You agree that we may use those measures. • Storage/Network Use. You may also store or install a copy of the Product on a storage device, such as a network server, used only to install or run the Product on your other Workstation Computers over an internal network; however, you must acquire and dedicate an additional license for each separate Workstation Computer on or from which the Product is installed, used, accessed, displayed or run. A license for the Product may not be shared or used concurrently on different Workstation Computers. • Reservation of Rights. Microsoft reserves all rights not expressly granted to you in this EULA.

2. UPGRADES. To use a Product identified as an upgrade, you must first be licensed for the product identified by Microsoft as eligible for the upgrade. After upgrading, you may no longer use the product that formed the basis for your upgrade eligibility.

3. ADDITIONAL SOFTWARE/SERVICES. This EULA applies to updates, supplements, add-on components, or Internet-based services components, of the Product that Microsoft may provide to you or make available to you after the date you obtain your initial copy of the Product, unless we provide other terms along with the update, supplement, add-on component, or Internet-based services component. Microsoft reserves the right to discontinue any Internet-based services provided to you or made available to you through the use of the Product. This EULA does not grant you any rights to use the Windows Media Format Software Development Kit ("WMFSDK") components contained in the Product to develop a software application that uses Windows Media technology. If you wish to use the WMFSDK to develop such an application, visit http://msdn.microsoft.com/workshop/imedia/windowsmedia/sdk/wmsdk.asp, accept a separate license for the WMFSDK, download the appropriate WMFSDK, and install it on your system.

4. TRANSFER—Internal. You may move the Product to a different Workstation Computer. After the transfer, you must completely remove the Product from the former Workstation Computer. Transfer to Third Party. The initial user of the Product may make a one-time transfer of the Product to another end user. The transfer has to include all component parts, media, printed materials, this EULA, and if applicable, the Certificate of Authenticity. The transfer may not be an indirect transfer, such as a consignment. Prior to the transfer, the end user receiving the transferred Product must agree to all the EULA terms. No Rental. You may not rent, lease, lend or provide commercial hosting services to third parties with the Product.

5. LIMITATION ON REVERSE ENGINEERING, DECOMPILATION, AND DISASSEMBLY. You may not reverse engineer, decompile, or disassemble the Product, except and only to the extent that it is expressly permitted by applicable law notwithstanding this limitation.

6. TERMINATION. Without prejudice to any other rights, Microsoft may cancel this EULA if you do not abide by the terms and conditions of this EULA, in which case you must destroy all copies of the Product and all of its component parts.

7. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. • NetMeeting?/Remote Assistance/Remote Desktop Features. The Product contains NetMeeting?, Remote Assistance, and Remote Desktop technologies that enable the Product or other applications installed on the Workstation Computer to be used remotely between two or more computers, even if the Product or application is installed on only one Workstation Computer. You may use NetMeeting?, Remote Assistance, and Remote Desktop with all Microsoft products; provided however, use of these technologies with certain Microsoft products may require an additional license. For Microsoft and non-Microsoft products, you should consult the license agreement accompanying the applicable product or contact the applicable licensor to determine whether use of NetMeeting?, Remote Assistance, or Remote Desktop is permitted without an additional license. • Consent to Use of Data. You agree that Microsoft and its affiliates may collect and use technical information gathered in any manner as part of the product support services provided to you, if any, related to the Product. Microsoft may use this information solely to improve our products or to provide customized services or technologies to you. Microsoft may disclose this information to others, but not in a form that personally identifies you. • Internet Gaming/Update Features. If you choose to utilize the Internet gaming or update features within the Product, it is necessary to use certain computer system, hardware, and software information to implement the features. By using these features, you explicitly authorize Microsoft or its designated agent to access and utilize the necessary information for Internet gaming and/or updating purposes. Microsoft may use this information solely to improve our products or to provide customized services or technologies to you. Microsoft may disclose this information to others, but not in a form that personally identifies you. • Internet-Based Services Components. The Product contains components that enable and facilitate the use of certain Internet-based services. You acknowledge and agree that Microsoft may automatically check the version of the Product and/or its components that you are utilizing and may provide upgrades or fixes to the Product that will be automatically downloaded to your Workstation Computer. • Security Updates. Content providers are using the digital rights management technology ("Microsoft DRM") contained in this Product to protect the integrity of their content ("Secure Content") so that their intellectual property, including copyright, in such content is not misappropriated. Owners of such Secure Content ("Secure Content Owners") may, from time to time, request Microsoft to provide security related updates to the Microsoft DRM components of the Product ("Security Updates") that may affect your ability to copy, display and/or play Secure Content through Microsoft software or third party applications that utilize Microsoft DRM. You therefore agree that, if you elect to download a license from the Internet which enables your use of Secure Content, Microsoft may, in conjunction with such license, also download onto your computer such Security Updates that a Secure Content Owner has requested that Microsoft distribute. Microsoft will not retrieve any personally identifiable information, or any other information, from your computer by downloading such Security Updates.

8. NOT FOR RESALE SOFTWARE. Product identified as "Not for Resale" or "NFR," may not be resold, transferred or used for any purpose other than demonstration, test or evaluation.

9. ACADEMIC EDITION SOFTWARE. To use Product identified as "Academic Edition" or "AE," you must be a "Qualified Educational User." For qualification-related questions, please contact the Microsoft Sales Information Center/One Microsoft Way/Redmond, WA 98052-6399 or the Microsoft subsidiary serving your country.

10. EXPORT RESTRICTIONS. You acknowledge that the Product is of U.S. origin and subject to U.S. export jurisdiction. You agree to comply with all applicable international and national laws that apply to the Product, including the U.S. Export Administration Regulations, as well as end-user, end-use, and destination restrictions issued by U.S. and other governments. For additional information see http://www.microsoft.com/exporting/.

11. LIMITED WARRANTY FOR PRODUCT ACQUIRED IN THE US AND CANADA. Microsoft warrants that the Product will perform substantially in accordance with the accompanying materials for a period of ninety days from the date of receipt. If an implied warranty or condition is created by your state/jurisdiction and federal or state/provincial law prohibits disclaimer of it, you also have an implied warranty or condition, BUT ONLY AS TO DEFECTS DISCOVERED DURING THE PERIOD OF THIS LIMITED WARRANTY (NINETY DAYS). AS TO ANY DEFECTS DISCOVERED AFTER THE NINETY (90) DAY PERIOD, THERE IS NO WARRANTY OR CONDITION OF ANY KIND. Some states/jurisdictions do not allow limitations on how long an implied warranty or condition lasts, so the above limitation may not apply to you. Any supplements or updates to the Product, including without limitation, any (if any) service packs or hot fixes provided to you after the expiration of the ninety day Limited Warranty period are not covered by any warranty or condition, express, implied or statutory. LIMITATION ON REMEDIES; NO CONSEQUENTIAL OR OTHER DAMAGES. Your exclusive remedy for any breach of this Limited Warranty is as set forth below. Except for any refund elected by Microsoft, YOU ARE NOT ENTITLED TO ANY DAMAGES, INCLUDING BUT NOT LIMITED TO CONSEQUENTIAL DAMAGES, if the Productdoes not meet Microsoft's Limited Warranty, and, to the maximum extent allowed by applicable law, even if any remedy fails of its essential purpose. The terms of Section 13 below ("Exclusion of Incidental, Consequential and Certain Other Damages") are also incorporated into this Limited Warranty. Some states/jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation or exclusion may not apply to you. This Limited Warranty gives you specific legal rights. You may have others which vary from state/jurisdiction to state/jurisdiction. YOUR EXCLUSIVE REMEDY. Microsoft's and its suppliers' entire liability and your exclusive remedy shall be, at Microsoft's option from time to time exercised subject to applicable law, (a) return of the price paid (if any) for the Product, or (b) repair or replacement of the Product, that does not meet this Limited Warranty and that is returned to Microsoft with a copy of your receipt. You will receive the remedy elected by Microsoft without charge, except that you are responsible for any expenses you may incur (e.g. cost of shipping the Product to Microsoft). This Limited Warranty is void if failure of the Product has resulted from accident, abuse, misapplication, abnormal use or a virus. Any replacement Product will be warranted for the remainder of the original warranty period or thirty (30) days, whichever is longer. Outside the United States or Canada, neither these remedies nor any product support services offered by Microsoft are available without proof of purchase from an authorized international source. To exercise your remedy, contact: Microsoft, Attn. Microsoft Sales Information Center/One Microsoft Way/Redmond, WA 98052-6399, or the Microsoft subsidiary serving your country. LIMITED WARRANTY FOR PRODUCT ACQUIRED OUTSIDE THE US OR CANADA. FOR THE LIMITED WARRANTIES AND SPECIAL PROVISIONS PERTAINING TO YOUR PARTICULAR JURISDICTION, PLEASE REFER TO YOUR WARRANTY BOOKLET INCLUDED WITH THIS PACKAGE OR PROVIDED WITH THE SOFTWARE PRODUCT PRINTED MATERIALS.

12. DISCLAIMER OF WARRANTIES. The Limited Warranty that appears above is the only express warranty made to you and is provided in lieu of any other express warranties (if any) created by any documentation, packaging, or other communications. Except for the Limited Warranty and to the maximum extent permitted by applicable law, Microsoft and its suppliers provide the Productand support services (if any) AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the Product, and the provision of or failure to provide support or other services, information, software, and related content through the Product or otherwise arising out of the use of the Product. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THE PRODUCT.

13. EXCLUSION OF INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, PUNITIVE, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR PERSONAL INJURY, FOR LOSS OF PRIVACY, FOR FAILURE TO MEET ANY DUTY INCLUDING OF GOOD FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, AND FOR ANY OTHER PECUNIARY OR OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE PRODUCT, THE PROVISION OF OR FAILURE TO PROVIDE SUPPORT OR OTHER SERVICES, INFORMATON, SOFTWARE, AND RELATED CONTENT THROUGH THE PRODUCT OR OTHERWISE ARISING OUT OF THE USE OF THE PRODUCT, OR OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS EULA, EVEN IN THE EVENT OF THE FAULT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY, BREACH OF CONTRACT OR BREACH OF WARRANTY OF MICROSOFT OR ANY SUPPLIER, AND EVEN IF MICROSOFT OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

14. LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Product. The third party sites are not under the control of Microsoft, and Microsoft is not responsible for the contents of any third party sites, any links contained in third party sites, or any changes or updates to third party sites. Microsoft is not responsible for webcasting or any other form of transmission received from any third party sites. Microsoft is providing these links to third party sites to you only as a convenience, and the inclusion of any link does not imply an endorsement by Microsoft of the third party site.

15. LIMITATION OF LIABILITY AND REMEDIES. Notwithstanding any damages that you might incur for any reason whatsoever (including, without limitation, all damages referenced above and all direct or general damages), the entire liability of Microsoft and any of its suppliers under any provision of this EULA and your exclusive remedy for all of the foregoing (except for any remedy of repair or replacement elected by Microsoft with respect to any breach of the Limited Warranty) shall be limited to the greater of the amount actually paid by you for the Productor U.S.$5.00. The foregoing limitations, exclusions and disclaimers (including Sections 11, 12 and 13 above) shall apply to the maximum extent permitted by applicable law, even if any remedy fails its essential purpose.

16. U.S. GOVERNMENT LICENSE RIGHTS. All Product provided to the U.S. Government pursuant to solicitations issued on or after December 1, 1995 is provided with the commercial license rights and restrictions described elsewhere herein. All Product provided to the U.S. Government pursuant to solicitations issued prior to December 1, 1995 is provided with "Restricted Rights" as provided for in FAR, 48 CFR 52.227-14 (JUNE 1987) or DFAR, 48 CFR 252.227-7013 (OCT 1988), as applicable.

17. APPLICABLE LAW. If you acquired this Product in the United States, this EULA is governed by the laws of the State of Washington. If you acquired this Product in Canada, unless expressly prohibited by local law, this EULA is governed by the laws in force in the Province of Ontario, Canada; and, in respect of any dispute which may arise hereunder, you consent to the jurisdiction of the federal and provincial courts sitting in Toronto, Ontario. If this Product was acquired outside the United States, then local law may apply.

18. ENTIRE AGREEMENT. This EULA (including any addendum or amendment to this EULA which is included with the Product) are the entire agreement between you and Microsoft relating to the Product and the support services (if any) and they supersede all prior or contemporaneous oral or written communications, proposals and representations with respect to the Product or any other subject matter covered by this EULA. To the extent the terms of any Microsoft policies or programs for support services conflict with the terms of this EULA, the terms of this EULA shall control.

19.The Product is protected by copyright and other intellectual property laws and treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the Product. The Product is licensed, not sold.

1.2 LICENÇA NÃO-PROPRIETÁRIA GPL

Disponível no site http://www.gnu.org/
Acesso em 10/01/2005

LICENÇA PÚBLICA GERAL GNU

Versão 2, junho de 1991

This is an unofficial translation of the GNU General Public License into Brazilian Portuguese. It was not published by the Free Software Foundation, and does not legally state the distribution terms for software that uses the GNU GPL -- only the original English text of the GNU GPL does that. However, we hope that this translation will help Brazilian Portuguese speakers understand the GNU GPL better.

Esta é uma tradução não-oficial da Licença Pública Geral GNU ("GPL GNU") para o português do Brasil. Ela não foi publicada pela FreeSoftware? Foundation, e legalmente não afirma os termos de distribuição de software que utiliza a GPL GNU -- apenas o texto original da GPL GNU, em inglês, faz isso. Contudo, esperamos que esta tradução ajude aos que utilizam o português do Brasil a entender melhor a GPL GNU.

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA

A qualquer pessoa é permitido copiar e distribuir cópias desse documento de licença, desde que sem qualquer alteração.

Introdução

As licenças de muitos software são desenvolvidas para restringir sua liberdade de compartilhá-lo e mudá-lo. Contrária a isso, a Licença Pública Geral GNU pretende garantir sua liberdade de compartilhar e alterar software livres -- garantindo que o software será livre e gratuito para os seus usuários. Esta Licença Pública Geral aplica-se à maioria dos software da Free Software Foundation e a qualquer outro programa cujo autor decida aplicá-la. (Alguns outros software da FSF são cobertos pela Licença Pública Geral de Bibliotecas, no entanto.) Você pode aplicá-la também aos seus programas.

Quando nos referimos a software livre, estamos nos referindo a liberdade e não a preço. Nossa Licença Pública Geral foi desenvolvida para garantir que você tenha a liberdade de distribuir cópias de software livre (e cobrar por isso, se quiser); que você receba o código-fonte ou tenha acesso a ele, se quiser; que você possa mudar o software ou utilizar partes dele em novos programas livres e gratuitos; e que você saiba que pode fazer tudo isso.

Para proteger seus direitos, precisamos fazer restrições que impeçam a qualquer um negar estes direitos ou solicitar que você deles abdique. Estas restrições traduzem-se em certas responsabilidades para você, se você for distribuir cópias do software ou modificá-lo.

Por exemplo, se você distribuir cópias de um programa, gratuitamente ou por alguma quantia, você tem que fornecer aos recebedores todos os direitos que você possui. Você tem que garantir que eles também recebam ou possam obter o código-fonte. E você tem que mostrar-lhes estes termos para que eles possam conhecer seus direitos.

Nós protegemos seus direitos em dois passos: (1) com copyright do software e (2) com a oferta desta licença, que lhe dá permissão legal para copiar, distribuir e/ou modificar o software.

Além disso, tanto para a proteção do autor quanto a nossa, gostaríamos de certificar-nos que todos entendam que não há qualquer garantia nestes software livres. Se o software é modificado por alguém mais e passado adiante, queremos que seus recebedores saibam que o que eles obtiveram não é original, de forma que qualquer problema introduzido por terceiros não interfira na reputação do autor original.

Finalmente, qualquer programa é ameaçado constantemente por patentes de software. Queremos evitar o perigo de que distribuidores desoftware livre obtenham patentes individuais, o que tem o efeito de tornar o programa proprietário. Para prevenir isso, deixamos claro que qualquer patente tem que ser licenciada para uso livre e gratuito por qualquer pessoa, ou então que nem necessite ser licenciada.

Os termos e condições precisas para cópia, distribuição e modificação se encontram abaixo:

LICENÇA PÚBLICA GERAL GNU

TERMOS E CONDIÇÕES PARA CÓPIA, DISTRIBUIÇÃO E MODIFICAÇÃO

0. Esta licença se aplica a qualquer programa ou outro trabalho que contenha um aviso colocado pelo detentor dos direitos autorais informando que aquele pode ser distribuído sob as condições desta Licença Pública Geral. O "Programa" abaixo refere-se a qualquer programa ou trabalho, e "trabalho baseado no Programa" significa tanto o Programa em si como quaisquer trabalhos derivados, de acordo com a lei de direitos autorais: isto quer dizer um trabalho que contenha o Programa ou parte dele, tanto originalmente ou com modificações, e/ou tradução para outros idiomas. (Doravante o processo de tradução está incluído sem limites no termo "modificação".) Cada licenciado é mencionado como "você".

Atividades outras que a cópia, a distribuição e modificação não estão cobertas por esta Licença; elas estão fora de seu escopo. O ato de executar o Programa não é restringido e o resultado do Programa é coberto apenas se seu conteúdo contenha trabalhos baseados no Programa (independentemente de terem sido gerados pela execução do Programa). Se isso é verdadeiro depende do que o programa faz.

1. Você pode copiar e distribuir cópias fiéis do código-fonte do Programa da mesma forma que você o recebeu, usando qualquer meio, deste que você conspícua e apropriadamente publique em cada cópia um aviso de direitos autorais e uma declaração de inexistência de garantias; mantenha intactas todos os avisos que se referem a esta Licença e à ausência total de garantias; e forneça a outros recebedores do Programa uma cópia desta Licença, junto com o Programa. Você pode cobrar pelo ato físico de transferir uma cópia e pode, opcionalmente, oferecer garantia em troca de pagamento.

2. Você pode modificar sua cópia ou cópias do Programa, ou qualquer parte dele, assim gerando um trabalho baseado no Programa, e copiar e distribuir essas modificações ou trabalhos sob os temos da seção 1 acima, desde que você também se enquadre em todas estas condições: a) Você tem que fazer com que os arquivos modificados levem avisos proeminentes afirmando que você alterou os arquivos, incluindo a data de qualquer alteração.

b) Você tem que fazer com que quaisquer trabalhos que você distribua ou publique, e que integralmente ou em partes contenham ou sejam derivados do Programa ou de suas partes, sejam licenciados, integralmente e sem custo algum para quaisquer terceiros, sob os termos desta Licença.

c) Se qualquer programa modificado normalmente lê comandos interativamente quando executados, você tem que fazer com que, quando iniciado tal uso interativo da forma mais simples, seja impresso ou mostrado um anúncio de que não há qualquer garantia (ou então que você fornece a garantia) e que os usuários podem redistribuir o programa sob estas condições, ainda informando os usuários como consultar uma cópia desta Licença. (Exceção: se o Programa em si é interativo mas normalmente não imprime estes tipos de anúncios, seu trabalho baseado no Programa não precisa imprimir um anúncio.)

Estas exigências aplicam-se ao trabalho modificado como um todo. Seseções identificáveis de tal trabalho não são derivadas do Programa, epodem ser razoavelmente consideradas trabalhos independentes e separados por si só, então esta Licença, e seus termos, não se aplicam a estas seções quando você distribui-las como trabalhos em separado. Mas quando você distribuir as mesmas seções como parte de um todo que é trabalho baseado no Programa, a distribuição como um todo tem que se enquadrar nos termos desta Licença, cujas permissões para outros licenciados se estendem ao todo, portanto também para cada e toda parte independente de quem a escreveu.

Desta forma, esta seção não tem a intenção de reclamar direitos os contestar seus direitos sobre o trabalho escrito completamente por você; ao invés disso, a intenção é a de exercitar o direito de controlar a distribuição de trabalhos, derivados ou coletivos, baseados no Programa.

Adicionalmente, a mera adição ao Programa de outro trabalho não baseado no Programa (ou de trabalho baseado no Programa) em um volume de armazenamento ou meio de distribuição não faz o outro trabalho parte do escopo desta Licença.

3. Você pode copiar e distribuir o Programa (ou trabalho baseado nele, conforme descrito na Seção 2) em código-objeto ou em formaexecutável sob os termos das Seções 1 e 2 acima, desde que você faça um dos seguintes:

a) O acompanhe com o código-fonte completo e em forma acessível por máquinas, que tem que ser distribuído sob os termos das Seções 1 e 2 acima e em meio normalmente utilizado para o intercâmbio de software; ou,

b) O acompanhe com uma oferta escrita, válida por pelo menos três anos, de fornecer a qualquer, com um custo não superior ao custo de distribuição física do material, uma cópia do código-fonte completo e em forma acessível por máquinas, que tem que ser distribuído sob os termos das Seções 1 e 2 acima e em meio normalmente utilizado para o intercâmbio de software; ou,

c) O acompanhe com a informação que você recebeu em relação à oferta de distribuição do código-fonte correspondente. (Esta alternativa é permitida somente em distribuição não comerciais, e apenas se você recebeu o programa em forma de código-objeto ou executável, com oferta de acordo com a Subseção b acima.)

O código-fonte de um trabalho corresponde à forma de trabalho preferida para se fazer modificações. Para um trabalho em forma executável, o código-fonte completo significa todo o código-fonte de todos os módulos que ele contém, mais quaisquer arquivos de definição de "interface", mais os "scripts" utilizados para se controlar a compilação e a instalação do executável. Contudo, como exceção especial, o código-fonte distribuído não precisa incluir qualquer componente normalmente distribuído (tanto em forma original quanto binária) com os maiores componentes (o compilador, o "kernel" etc.) do sistema operacional sob o qual o executável funciona, a menos que o componente em si acompanhe o executável.

Se a distribuição do executável ou código-objeto é feita através da oferta de acesso a cópias de algum lugar, então ofertar o acesso equivalente a cópia, do mesmo lugar, do código-fonte equivale à distribuição do código-fonte, mesmo que terceiros não sejam compelidos a copiar o código-fonte com o código-objeto.

4. Você não pode copiar, modificar, sub-licenciar ou distribuir o Programa, exceto de acordo com as condições expressas nesta Licença. Qualquer outra tentativa de cópia, modificação, sub-licenciamento ou distribuição do Programa não é valida, e cancelará automaticamente os direitos que lhe foram fornecidos por esta Licença. No entanto, terceiros que de você receberam cópias ou direitos, fornecidos sob os termos desta Licença, não terão suas licenças terminadas, desde que permaneçam em total concordância comela.

5. Você não é obrigado a aceitar esta Licença já que não a assinou. No entanto, nada mais o dará permissão para modificar ou distribuir o Programa ou trabalhos derivados deste. Estas ações são proibidas por lei, caso você não aceite esta Licença. Desta forma, ao modificar ou distribuir o Programa (ou qualquer trabalho derivado do Programa), você estará indicando sua total aceitação desta Licença para fazê-los, e todos os seus termos e condições para copiar, distribuir ou modificar o Programa, ou trabalhos baseados nele.

6. Cada vez que você redistribuir o Programa (ou qualquer trabalho baseado nele), os recebedores adquirirão automaticamente do licenciador original uma licença para copiar, distribuir ou modificar o Programa, sujeitos a estes termos e condições. Você não poderá impor aos recebedores qualquer outra restrição ao exercício dos direitos então adquiridos. Você não é responsável em garantir a concordância de terceiros a esta Licença.

7. Se, em conseqüência de decisões judiciais ou alegações de infringimento de patentes ou quaisquer outras razões (não limitadas a assuntos relacionados a patentes), condições forem impostas a você (por ordem judicial, acordos ou outras formas) e que contradigam as condições desta Licença, elas não o livram das condições desta Licença. Se você não puder distribuir de forma a satisfazer simultaneamente suas obrigações para com esta Licença e para com as outras obrigações pertinentes, então como conseqüência você não poderá distribuir o Programa. Por exemplo, se uma licença de patente não permitirá a redistribuição, livre de "royalties", do Programa, por todos aqueles que receberem cópias direta ou indiretamente de você, então a única forma de você satisfazer a ela e a esta Licença seria a de desistir completamente de distribuir o Programa.

Se qualquer parte desta seção for considerada inválida ou não aplicável em qualquer circunstância particular, o restante da seção se aplica, e a seção como um todo se aplica em outras circunstâncias.

O propósito desta seção não é o de induzi-lo a infringir quaisquer patentes ou reivindicação de direitos de propriedade outros, ou acontestar a validade de quaisquer dessas reivindicações; esta seção tem como único propósito proteger a integridade dos sistemas de distribuição de software livres, o que é implementado pela prática de licenças públicas. Várias pessoas têm contribuído generosamente e em grande escala para os software distribuídos usando este sistema, na certeza de que sua aplicação é feita de forma consistente; fica a critério do autor/doador decidir se ele ou ela está disposto a distribuir software utilizando outro sistema, e um licenciado não pode impor qualquer escolha.

Esta seção destina-se a tornar bastante claro o que se acredita ser conseqüência do restante desta Licença.

8. Se a distribuição e/ou uso do Programa são restringidos em certos países por patentes ou direitos autorais, o detentor dos direitos autorais original, e que colocou o Programa sob esta Licença, pode incluir uma limitação geográfica de distribuição, excluindo aqueles países de forma a tornar a distribuição permitida apenas naqueles ou entre aqueles países então não excluídos. Nestes casos, esta Licença incorpora a limitação como se a mesma constasse escrita nesta Licença.

9. A Free Software Foundation pode publicar versões revisadas e/ou novas da Licença Pública Geral de tempos em tempos. Estas novas versões serão similares em espírito à versão atual, mas podem diferir em detalhes que resolvem novos problemas ou situações.

A cada versão é dada um número distinto. Se o Programa especifica um número de versão específico desta Licença que se aplica a ele e a "qualquer nova versão", você tem a opção de aceitar os termos e condições daquela versão ou de qualquer outra versão publicada pela Free Software Foundation. Se o programa não especifica um número de versão desta Licença, você pode escolher qualquer versão já publicada pela Free Software Foundation.

10. Se você pretende incorporar partes do Programa em outros programas livres cujas condições de distribuição são diferentes, escreva ao autor e solicite permissão. Para o software que a Free Software Foundation detém direitos autorais, escreva à Free Software Foundation; às vezes nós permitimos exceções a este caso. Nossa decisão será guiada pelos dois objetivos de preservar a condição de liberdade de todas as derivações do nosso software livre, e de promover o compartilhamento e reutilização de software em aspectos gerais.

AUSÊNCIA DE GARANTIAS

11. UMA VEZ QUE O PROGRAMA É LICENCIADO SEM ÔNUS, NÃO HÁ QUALQUER GARANTIA PARA O PROGRAMA, NA EXTENSÃO PERMITIDA PELAS LEIS APLICÁVEIS. EXCETO QUANDO EXPRESSADO DE FORMA ESCRITA, OS DETENTORES DOS DIREITOS AUTORAIS E/OU TERCEIROS DISPONIBILIZAM O PROGRAMA "NO ESTADO", SEM QUALQUER TIPO DE GARANTIAS, EXPRESSAS OU IMPLÍCITAS, INCLUINDO, MAS NÃO LIMITADO A, AS GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO E AS DE ADEQUAÇÃO A QUALQUER PROPÓSITO. O RISCO TOTAL COM A QUALIDADE E DESEMPENHO DO PROGRAMA É SEU. SE O PROGRAMA SE MOSTRAR DEFEITUOSO, VOCÊ ASSUME OS CUSTOS DE TODAS AS MANUTENÇÕES, REPAROS E CORREÇÕES.

12. EM NENHUMA OCASIÃO, A MENOS QUE EXIGIDO PELAS LEIS APLICÁVEIS OU ACORDO ESCRITO, OS DETENTORES DOS DIREITOS AUTORAIS, OU QUALQUER OUTRA PARTE QUE POSSA MODIFICAR E/OU REDISTRIBUIR O PROGRAMA CONFORME PERMITIDO ACIMA, SERÃO RESPONSABILIZADOS POR VOCÊ POR DANOS, INCLUINDO QUALQUER DANO EM GERAL, ESPECIAL, ACIDENTAL OU CONSEQÜENTE, RESULTANTES DO USO OU INCAPACIDADE DE USO DO PROGRAMA (INCLUINDO, MAS NÃO LIMITADO A, A PERDA DE DADOS OU DADOS TORNADOS INCORRETOS, OU PERDAS SOFRIDAS POR VOCÊ OU POR OUTRAS PARTES, OU FALHAS DO PROGRAMA AO OPERAR COM QUALQUER OUTRO PROGRAMA), MESMO QUE TAL DETENTOR OU PARTE TENHAM SIDO AVISADOS DA POSSIBILIDADE DE TAIS DANOS.

FIM DOS TERMOS E CONDIÇÕES Como Aplicar Estes Termos aos Seus Novos Programas

Se você desenvolver um novo programa, e quer que ele seja utilizado amplamente pelo público, a melhor forma de alcançar este objetivo é torná-lo software livre que qualquer um pode redistribuir e alterar, sob estes termos. Para isso, anexe os seguintes avisos ao programa. É mais seguro anexá-los logo no início de cada arquivo-fonte para reforçarem mais efetivamente a inexistência de garantias; e cada arquivo deve possuir pelo menos a linha de "copyright" e uma indicação de onde o texto completo se encontra.

Copyright (C)

Este programa é software livre; você pode redistribuí-lo e/ou modificá-lo sob os termos da Licença Pública Geral GNU, conforme publicada pela Free Software Foundation; tanto a versão 2 da Licença como (a seu critério) qualquer versão mais nova.

Este programa é distribuído na expectativa de ser útil, mas SEM QUALQUER GARANTIA; sem mesmo a garantia implícita de COMERCIALIZAÇÃO ou de ADEQUAÇÃO A QUALQUER PROPÓSITO EM PARTICULAR. Consulte a Licença Pública Geral GNU para obter mais detalhes.

Você deve ter recebido uma cópia da Licença Pública Geral GNU junto com este programa; se não, escreva para a Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

Inclua também informações sobre como contactá-lo eletronicamente e por carta.

Se o programa é interativo, faça-o mostrar um aviso breve como este, ao iniciar um modo interativo:

Gnomovision versão 69, Copyright (C) ano nome do autor O Gnomovision não possui QUALQUER GARANTIA; para obter mais detalhes digite `show w'. Ele é software livre e você está convidado a redistribui-lo sob certas condições; digite `show c' para obter detalhes.

Os comandos hipotéticos `show w' e `show c' devem mostrar as partes apropriadas da Licença Pública Geral. Claro, os comandos que você usar podem ser ativados de outra forma que `show w' e `show c'; eles podem até ser cliques do mouse ou itens de um menu -- o que melhor se adequar ao programa.

Você também deve obter do seu empregador (se você trabalha como programador) ou escola, se houver, uma "declaração de ausência de direitos autorais" sobre o programa, se necessário. Aqui está um exemplo; altere os nomes:

Yoyodyne, Inc., aqui declara a ausência de quaisquer direitos autorais sobre o programa `Gnomovision' (que executa interpretações em compiladores) escrito por James Hacker.

, 1o. de abril de 1989 Ty Con, Vice-presidente

Esta Licença Pública Geral não permite incorporar seu programa em programas proprietários. Se seu programa é uma biblioteca de sub-rotinas, você deve considerar mais útil permitir ligar aplicações proprietárias com a biblioteca. Se isto é o que você deseja, use a Licença Pública Geral de Bibliotecas GNU, ao invés desta Licença

ANEXO II

CARTA DA MICROSOFT NO PERÚ

Disponível no site: http://www.opensource.org/docs/msFUD_to_peru.php.
Acesso em 15/01/2005

Microsoft's "Fear, Uncertainty and Doubt" (F.U.D.) letter to Peru concerning free and open source software.

The entirity of the Microsoft letter:

(and scanned copies 1 2 3)

"San Isidro, March 21st 2002

Mr: Edgar Villanueva Nuñez Congressman of the Republic of Peru

Present.-

Dear sir:

First of all, we want to thank you for the chance you gave us to inform you about our work in this country for benefit of the public sector, always looking for the best ways to implement programs that will let us consolidate the initiatives of modernization and transparency in the State.

In fact, thanks to our meeting today you are aware of our global achievements at the international level in the design of new services for the citizen, within the framework of a model State that respects and protects intellectual property.

The actions we talked about are part of a global initiative, and today there exist several experiences which have let us collaborate with programs supporting the State and community in the adoption of technology as a strategic element impacting the quality of life of the citizens.

Furthermore, as arranged in this meeting, we assisted the forum organized in the Congress on March 6th regarding the law project that you are leading, wherein we got the chance to listen to several presentations which lead us now to explain our position so you have a wider grasp of the real situation.

The bill makes it compulsory for all public bodies to use only free software, that is to say open source software, which breaches the principles of equality before the law, that of non-discrimination and the right of free private enterprise, freedom of industry and of contract, protected by the constitution.

The bill, by making the use of open source software compulsory, would establish discriminatory and non competitive practices in the contracting and purchasing by public bodies, violating the base principles of the "Law of State Contracting and Aquisitions" (Number 26850)

So, by compelling the State to favour a business model based entirely on open source, the bill would only discourage the local and international manufacturing companies, which are the ones which really undertake important expenditures, create a significant number of direct and indirect jobs, as well as contributing to the GNP, as opposed to a model of open source software which tends to have an ever weaker economic impact, since it mainly creates jobs in the service sector.

The bill imposes the use of open source software without considering the dangers that this can bring from the point of view of security, guarantee, and possible violation of the intellectual property rights of third parties.

The bill uses the concept of open source software incorrectly, since it does not necessarily imply that the software is free or of zero cost, and so arrives at mistaken conclusions regarding State savings, with no cost-benefit analysis to validate its position.

It is wrong to think that Open Source Software is free of charge. Research by the Gartner Group (an important investigator of the technological market recognized at world level) has shown that the cost of purchase of software (operating system and applications) is only 8% of the total cost which firms and institutions take on for a rational and truely beneficial use of the technology. The other 92% consists of: installation costs, enabling, support, maintenance, administration, and down-time.

One of the arguments behind the bill is the supposed freedom from costs of open-source software, compared with the costs of commercial software, without taking into account the fact that there exist types of volume licensing which can be highly advantageous for the State, as has happened in other countries.

In addition, the alternative adopted by the bill (i) is clearly more expensive, due to the high costs of software migration, and (ii) puts at risk compatibility and interoperability of the IT platforms within the State, and between the State and the private sector, given the hundreds of versions of open source software on the market.

The majority of open source code does not offer adequate levels of service nor the guarantee from recognized manufacturers of high productivity on the part of the users, which has led various public organizations to retract their decision to go with an open source software solution and to use commercial software in its place.

The bill demotivates the creativity of the peruvian software industry, which invoices 40 million US$/year, exports 4 million US$ (10th in ranking among non-traditional exports, more than handicrafts) and is a source of highly qualified employment. With a law that incentivates the use of open source, software programmers lose their intellectual property rights and their main source of payment.

Open source software, since it can be distributed without charge, does not allow the generation of income for its developers through exports. In this way, the multiplier effect of the sale of software to other countries is weakened, and so in turn is the growth of the industry, while Government rules ought on the contrary to stimulate local industry.

In the Forum, the use of open source software in education was discussed, without mentioning the complete collapse of this initiative in a country like Mexico, where precisely the State employees who founded the project now state that open source software did not make it possible to offer a learning experience to pupils in the schools, did not take into account the capability at a national level to give adequate support to the platform, and that the software did not and does not allow for the levels of platform integration that now exist in schools.

If open source software satisfies all the requirements of State bodies, why do you need a law to adopt it? Shouldn't it be the market which decides freely which products give most benefits or value?

I really want to thank you for your attention to this letter, and we want to reiterate our interest in meeting you to explain to you in more detail our point of view about the bill you have presented, and to be at your complete disposal to share experiences and information which we are sure can help better analyse and implement an initiative looking to modernization and transparency of the State for the benefit of the citizen.

Sincerely,

Juan Alberto González

General Manager Microsoft Perú"

2.2- CARTA DO CONGRESSITA VILLANUEVA NUÑEZ

Disponível: http://www.opensource.org/docs/peru_to_ms_spanish.php.
Acesso em 15/01/2005

Lima, 08 de Abril del 2002.

Señor

JUAN ALBERTO GONZÁLEZ

Gerente General de Microsoft del Perú

Presente.-

Estimado Señor.

Ante todo, agradezco su carta del 25 de Marzo del 2002 donde manifiesta la posición oficial de Microsoft respecto al Proyecto de Ley Nº 1609, Software Libre en la Administración Pública, que sin duda se halla inspirada en el deseo de que el Perú logre situarse adecuadamente en el contexto tecnológico global. Animado de ese mismo espíritu y convencido de que a través del intercambio de ideas claras y abiertas hemos de encontrar las mejores soluciones, me permito contestar mediante la presente los comentarios incluidos en su carta.

Sin dejar de reconocer que opiniones como la suya constituyen un aporte significativo, me hubiese resultado aun mas valioso si, además de formular objeciones de índole general (que luego analizaremos en detalle) hubiera agregado argumentos sólidos sobre las ventajas que el software propietario puede reportar al Estado Peruano y a sus ciudadanos en general, pues ello habría permitido un intercambio a todas luces más esclarecedor respecto de cada una nuestras posiciones.

Con el objetivo de ordenar el debate, asumiremos que lo que Ud. llama "software de código abierto" es lo que el Proyecto define como "software libre", puesto que existe software cuyo código es distribuido junto con los programas, pero no encaja en la definición establecida en el Proyecto; y lo que Ud. llama "software comercial" es lo que el Proyecto define como "propietario" o "no libre", puesto que existe software libre que se comercializa en el mercado por un precio como cualquier otro bien o servicio.

También es preciso dejar en claro que el propósito del Proyecto al que nos referimos no está directamente relacionado con la cantidad de ahorro directo que pueda obtenerse por el empleo de software libre en las instituciones estatales. Este es en todo caso, un valor agregado marginal, pero de ninguna manera el foco del objetivo del Proyecto. Los principios elementales que animan al Proyecto se vinculan a las garantías básicas de un Estado democrático de derecho, como:

* Libre acceso del ciudadano a la información pública.

* Perennidad de los datos públicos.

* Seguridad del Estado y de los ciudadanos.

Para garantizar el libre acceso de los ciudadanos a la información pública, resulta indispensable que la codificación de los datos no esté ligada a un único proveedor. El uso de formatos estándar y abiertos permite garantizar este libre acceso, logrando si fuera necesario la creación de software libre compatible.

Para garantizar la perennidad de los datos públicos, es indispensable que la utilización y el mantenimiento del software no dependan de la buena voluntad de los proveedores, ni de las condiciones monopólicas impuestas por éstos. Por ello el Estado necesita sistemas cuya evolución pueda ser garantizada gracias a la disponibilidad del código fuente.

Para garantizar la seguridad del Estado o seguridad nacional, resulta indispensable contar con sistemas desprovistos de elementos que permitan el control a distancia o la transmisión no deseada de información a terceros. Por lo tanto, se requieren sistemas cuyo código fuente sea libremente accesible al público para permitir su examen por el propio Estado, los ciudadanos, y un gran número de expertos independientes en el mundo. Nuestra propuesta aporta mayor seguridad, pues el conocimiento del código fuente eliminará el creciente número de programas con código espía.

Asimismo, nuestra propuesta refuerza la seguridad de los ciudadanos, tanto en su condición de titulares legítimos de la información manejada por el estado, cuanto en su condición de consumidores. En este ultimo caso, al permitir el surgimiento de una oferta extensa de software libre desprovisto de potencial código espía susceptible de poner en riesgo la vida privada y las libertades individuales.

En este sentido, el Proyecto de Ley se limita a establecer las condiciones en que los organismos estatales adquirirán software en el futuro, es decir, de un modo compatible con la garantía de esos principios básicos.

De la lectura del Proyecto quedará claro que una vez aprobada:

* la ley no prohibe la producción de software propietario

* la ley no prohibe el comercio de software propietario

* la ley no dicta cuál software concreto usar

* la ley no dicta a que proveedor se compra el software

* la ley no limita los términos en que se puede licenciar un producto de software.

Lo que el proyecto expresa claramente es que, el software para ser aceptable para el Estado, no basta con que sea técnicamente suficiente para llevar a cabo una tarea, sino que además las condiciones de contratación deben satisfacer una serie de requisitos en materia de licencia, sin los cuales el Estado no puede garantizar al ciudadano el procesamiento adecuado de sus datos, velando por su integridad, confidencialidad y accesibilidad a lo largo del tiempo, porque son aspectos muy críticos para su normal desempeño.

Estamos de acuerdo Sr. González, en el hecho de que la tecnología de información y comunicaciones tiene un impacto en la calidad de vida de los ciudadanos significativo (sin que por ello sea siempre positivo o de efecto neutro). También coincidiremos seguramente, en que los valores básicos que he señalado arriba son fundamentales en una nación democrática como el Perú. Desde luego estamos muy interesados en conocer cualquier forma alternativa de garantizar estos principios, que no sea la de recurrir al empleo de software libre en los términos definidos en el Proyecto de Ley.

En cuanto a las observaciones que Ud. formula, pasaremos ahora a analizarlas en detalle:

En primer lugar, señala que: "1. El proyecto establece la obligatoriedad de que todo organismo público debe emplear exclusivamente software libre, es decir de código abierto, lo cual transgrede los principios de la igualdad ante la ley, el de no discriminación y los derechos a la libre iniciativa privada, libertad de industria y contratación protegidos en la constitución.".

Esta apreciación constituye un error. De ningún modo el proyecto afecta los derechos que Ud. enumera; sólo se limita a establecer condiciones para el empleo del software por parte de las instituciones estatales, sin inmiscuirse en modo alguno en las transacciones del sector privado. Es un principio bien establecido que el Estado no tiene el amplio espectro de libertad contractual del sector privado, pues precisamente esta limitado en su accionar por el deber de transparencia de los actos públicos; y en ese sentido, la preservación del mejor interés común debe prevalecer cuando se legisla sobre la materia.

El Proyecto protege la igualdad ante la Ley, pues ninguna persona natural o jurídica esta excluida del derecho de ofrecer estos bienes al Estado en las condiciones fijadas en el Proyecto y sin más limitaciones que las establecidas en la Ley de Contrataciones y Adquisiciones del Estado (T.U.O. por Decreto Supremo No. 012-2001-PCM).

El Proyecto no introduce discriminación alguna, pues sólo establece como han de proveerse estos bienes (lo cual es una potestad estatal) y no quien ha de proveerlos (lo que en efecto resultaría discriminatorio si se impusieran restricciones basadas en origen nacional, raza, religión, ideología, preferencia sexual, etc.) Por el contrario, el Proyecto es decididamente antidiscriminatorio. Es así porque al determinar sin lugar a dudas las condiciones de provisión del software, impide a los organismos estatales el uso de programas cuyo licenciamiento incluya condiciones discriminatorias.

Resulta obvio por lo expuesto en los dos párrafos previos, que el Proyecto no atenta contra la libre iniciativa privada, pues esta puede elegir siempre bajo que condiciones producirá el software; algunas de estas serán aceptables para el Estado, y otras no lo serán porque contrarían la garantía de los principios básicos enumerados arriba. Esta libre iniciativa es desde luego, compatible con la libertad de industria y con la libertad de contratación (en los términos acotados en que el Estado puede ejercer esta última). Cualquier sujeto privado puede producir software en las condiciones que el Estado lo requiere, o puede abstenerse de hacerlo. Nadie esta forzado a adoptar un modelo de producción, pero si desea proveer software al Estado, deberá proporcionar los mecanismos que garantizan los principios básicos, y que son los manifestados en el Proyecto.

A manera de ejemplo: nada en el texto del Proyecto impediría a su empresa ofrecer a los organismos del Estado su "suite" de oficina, en las condiciones definidas en el Proyecto y fijando el precio que ustedes consideren conveniente. Si no lo hiciera, no se deberá a restricciones impuestas por la ley, sino a decisiones empresariales respecto al modo de comercializar sus productos, decisiones, en que el Estado no tiene participación.

A continuación señala Ud. que: "2. El proyecto, al hacer obligatorio el uso de software de código abierto, establecería un tratamiento discriminatorio y no competitivo en la contratación y adquisición de los organismos públicos..."

Esta afirmación no es sino una reiteración de la anterior, y por ende se encuentra contestada lineas arriba. Pero detengámonos un instante en su apreciación sobre el "tratamiento ... no competitivo."

Por cierto, al definir cualquier tipo de adquisición, el comprador fija condiciones que se relacionan con el uso propuesto del bien o servicio. Desde luego ello excluye a ciertos fabricantes de la posibilidad de competir, pero no los excluye "a priori", sino en base a una serie de principios decididos por la voluntad autónoma del comprador, en tanto el proceso se lleve a cabo conforme a la ley. Y en el Proyecto se estable que nadie esta excluido de competir en tanto garantice el cumplimiento de los principios básicos.

Además el Proyecto estimula la competencia, pues alienta a generar oferta de software con mejores condiciones de usabilidad, y a optimizar trabajos ya establecidos, en un modelo de mejora constante.

De otro lado, el aspecto central de la competitividad es la oportunidad de proporcionar al consumidor mejores opciones. Ahora bien, es imposible desconocer que el marketing no juega un papel neutral a la hora de presentar la oferta al mercado (pues admitir lo contrario habilitaría a suponer que las inversiones que las empresas realizan en marketing carecen de sentido), y por consiguiente un gasto significativo en este rubro puede influir las decisiones del comprador. Esta influencia del marketing queda en buena medida mitigada por el proyecto que propulsamos, pues la elección dentro del marco propuesto recae en el mérito técnico del producto y no en el esfuerzo de comercialización del productor; en este sentido, la competitividad se acentúa, pues el más pequeño productor de software puede competir en un pie de igualdad con la más poderosa de las corporaciones.

Es necesario recalcar que no hay posición más anti-competitiva que la de los grandes productores de software propietario, que frecuentemente abusan de su posición dominante, porque en innumerables casos proponen como soluciones a problemas planteados por los usuarios: "actualice su software a la nueva versión" (con cargo para el usuario, por supuesto); además, son comunes las interrupciones arbitrarias de asistencia técnica para productos que al sólo juicio del proveedor, son "antiguos"; luego para recibir algún grado de asistencia técnica, el usuario se ve obligado a migrar (con costo no trivial, especialmente porque suele involucrar cambios de la plataforma de hardware) a nuevas versiones. Y como toda la infraestructura esta consolidada en formatos de datos propietarios, el usuario queda "atrapado" en la necesidad de continuar empleando los productos del mismo proveedor, o realizar el enorme esfuerzo de cambiar a otro ambiente (también probablemente propietario).

Agrega Ud.: "3. Así, al obligar al Estado a favorecer un modelo de negocios que apoyaría exclusivamente el software de código abierto, el proyecto sólo estaría desalentando a las compañías fabricantes locales e internacionales que son las que verdaderamente realizan importantes inversiones, crean un significativo número de puestos de empleos directos e indirectos, además de contribuir al PBI vs. Un modelo de software de código abierto que tiende a tener un impacto económico cada vez menor debido a que crea principalmente empleos en servicio."

No estoy de acuerdo con lo que Ud. afirma. En parte por lo que Ud. mismo señala en el párrafo 6 de su carta, respecto del peso relativo de los servicios en el contexto del uso de software. Esta contradicción, de por sí, invalidaría su postura. El modelo de servicios, adoptado por gran número de corporaciones en la industria informática, es mucho más significativo, en términos económicos y con tendencia creciente, que el licenciamiento de programas.

Por otra parte, el sector privado de la economía tiene la más amplia libertad para elegir el modelo económico que mas convenga a sus intereses, aunque esta libertad de elección quede muchas veces oscurecida de manera subliminal por las desproporcionadas inversiones en marketing de los productores de software propietario.

Adicionalmente, de la lectura de su opinión se desprendería que el mercado Estatal es crucial e imprescindible para la industria del software propietario, a tal punto que la opción que el Estado establece en este proyecto, eliminaría completamente del mercado a estas empresas. Si es así, deducimos que el Estado estaría subsidiando a la industria del software propietario. En el supuesto negado que esto fuese cierto, entonces el Estado tendría el derecho en aplicar los subsidios al área que considere de mayor valor social; resultaría innegable, en esta improbable hipótesis, que si el Estado decide subsidiar software debería hacerlo escogiendo el libre por encima del propietario, atendiendo a su efecto social y al uso racional de los dineros de los contribuyentes.

Respecto de los puestos de trabajo generados por el software propietario en países como el nuestro, estos tratan mayoritariamente tareas técnicas de poco valor agregado; a nivel local, los técnicos que prestan soporte a software propietario producido por empresas transnacionales no están en condiciones de solucionar un bug, no necesariamente por falta capacidad técnica o talento, sino porque no disponen del código fuente a reparar. Con software libre se crea empleo técnicamente más calificado y se genera un marco de libre competencia donde el éxito esta sólo vinculado a la capacidad de brindar buen soporte técnico y calidad de servicio, se estimula el mercado y se incrementa el patrimonio común del conocimiento, abriendo alternativas para generar servicios de mayor valor agregado y mejor perfil de calidad beneficiando a todos los actores: productores, prestadores de servicios y consumidores.

Es un fenómeno común en los países en vías de desarrollo que las industrias locales de software obtienen la mayoría de sus ingresos en el área de servicios, o en la construcción de software "ad hoc". Por lo tanto, cualquier impacto negativo que la aplicación del Proyecto pueda tener en este sector se verá compensado con creces por un aumento de la demanda de servicios (a condición de que estos sean prestados conforme a altos estándares de calidad). Desde luego, es probable que las empresas transnacionales de software si deciden no competir conforme a estas reglas de juego, sufran alguna disminución de ingresos en términos de facturación por licenciamiento; pero considerando, que estas empresas alegan sostenidamente que mucho del software empleado por el Estado fueron copiados ilegalmente, se verá que el impacto no ha de ser extremadamente serio. Ciertamente, en todo caso su fortuna estará determinada por leyes del mercado, cuyos cambios no es posible evitar; muchas empresas tradicionalmente asociadas con el software propietario ya han emprendido un camino firme (apoyado por cuantiosas inversiones) para prestar servicios asociados con el software libre, lo cual demuestra que los modelos no son mutuamente excluyentes.

Con este Proyecto el Estado está decidiendo que requiere preservar ciertos valores fundamentales. Y lo decide en base a sus potestades soberanas, sin afectar con ello ninguna de las garantías constitucionales. Si estos valores pueden ser garantizados sin tener que escoger un modelo económico dado, los efectos de la ley serían aun más beneficiosos. En todo caso debe quedar claro que el Estado no elige un modelo económico; si sucediera que existe un sólo modelo económico capaz de proveer software tal que satisfaga la garantía básicas de estos principios, se trataría de una circunstancia histórica y no de una decisión arbitraria en favor de un modelo dado.

Prosigue su carta: "4. El proyecto de ley impone el uso de software de código abierto sin considerar los peligros que esto pueda conllevar desde el punto de vista de seguridad, garantía y posible violación de los derechos de propiedad intelectual de terceros."

Aludir de forma abstracta "los peligros que pueda conllevar", sin especificar siquiera una sola instancia de esos supuestos peligros, denota cuando menos un desconocimiento del tema. Así, pues, permítame ilustrarlo sobre estos puntos.

Sobre seguridad:

En términos generales respecto la seguridad nacional, ya se mencionó inicialmente en los principios básicos del Proyecto. En términos más puntuales respecto de la seguridad del software en sí, es bien sabido que el software (propietario o libre) contiene errores de programación o "bugs" (en la jerga informática) en sus lineas de código. Pero también es público y notorio que los bugs en el software libre son menos, y se reparan mucho mas rápidamente, que en el software propietario. No en vano numerosas organismos públicos responsables por la seguridad informática de los sistemas estatales en países desarrollados prescriben el uso de software libre a iguales condiciones de seguridad y eficiencia.

Lo que resulta imposible probar es que el software propietario sea más seguro que el libre, salvo mediante el escrutinio publico y abierto de la comunidad científica y los usuarios en general. Esta demostración es imposible porque el propio modelo del software propietario impide este análisis, con lo que la garantía de seguridad se basa en la palabra bienintencionada (pero a todas luces parcial) del propio productor o sus contratistas.

Corresponde recordar que, en numerosos casos, las condiciones de licenciamiento incluyen cláusulas de Non-Disclosure que impiden a los usuarios revelar abiertamente las fallas de seguridad halladas en el producto propietario licenciado.

Respecto a garantía:

Como Ud. sabe perfectamente, o podrá determinar leyendo el "End User License Agreement" de los productos que licencia, en la amplísima mayoría de los casos, las garantías están limitadas a la reposición del medio de almacenamiento si este fuera defectuoso, pero en ningún caso se prevén compensaciones por daños directos o indirectos, lucro cesante, etc.. Si como consecuencia de un bug de seguridad en alguno de sus productos, no oportunamente reparado por Uds., un atacante comprometiera sistemas cruciales para el Estado: ¿que garantías, reparaciones y compensaciones proporcionaría su empresa de acuerdo con sus condiciones de licenciamiento? Las garantías del software propietario, en tanto los programas se entregan ``AS IS'', es decir, en el estado en que se encuentran, sin ninguna responsabilidad adicional para el proveedor respecto a su funcionalidad, no difieren en modo alguno de las habituales en el software libre.

Sobre la propiedad intelectual:

Las cuestiones de propiedad intelectual están fuera del ámbito en este proyecto, pues se encuentran amparadas por otras leyes específicas. El modelo de software libre no implica en modo alguno desconocer estas leyes y de hecho, la amplísima mayoría del software libre está amparado por el copyright. En realidad, la sola inclusión de esta cuestión en sus observaciones demuestra su confusión respecto del marco legal en que se desenvuelve el software libre. La incorporación de propiedad intelectual ajena en obras que luego se atribuyen como propias no es una práctica de la que se tenga registro en la comunidad del software libre; si lo es, lamentablemente, en el terreno del software propietario. Valga a titulo de ejemplo la condena de la Corte Comercial de Nanterre, Francia, del pasado 27 de septiembre de 2001 a Microsoft Corp., por 3 millones de francos en concepto de daños e intereses, por violación de la propiedad intelectual (piratería, según el desafortunado término que su empresa suele usar en su publicidad).

Prosigue diciendo que: "5. El proyecto maneja de manera errónea los conceptos de software de código abierto, que no necesariamente implica que sea software libre o de costo cero, llegando a realizar conclusiones equívocas sobre ahorros para el Estado, sin ningún sustento costo beneficio que valide la posición."

Esta observación no es así, en principio la gratuidad y la libertad son conceptos ortogonales: hay software propietario y oneroso (por ejemplo, MS Office), software propietario y gratuito (MS Internet Explorer), software libre y oneroso (distribuciones RedHat?, SuSE?, etc. del sistema GNU/Linux), software libre y gratuito (Apache, OpenOffice?, Mozilla), y aun software que se licencia bajo diferentes modalidades (MySQL?).

Ciertamente que el software libre no es necesariamente gratuito. Y tampoco se desprende del texto del Proyecto que deba serlo como bien habrá notado después de leer la norma propuesta. Las definiciones incluidas en el Proyecto determinan claramente que debe considerarse software libre, en ningún momento se refieren a la gratuidad. Si bien se mencionan las posibilidades de ahorro en términos de lo pagado por licencias de software propietario, los fundamentos del proyecto hacen clara mención a las garantías fundamentales que se pretende preservar y al estimulo del desarrollo tecnológico local. Puesto que un Estado democrático debe sostener estos principios, no le queda otra solución que emplear software cuyo código fuente está públicamente disponible e intercambiar información sólo en formatos standares.

Si el Estado no empleara software con esas características, estaría vulnerando principios republicanos básicos. Por fortuna, además, el software libre implica menores costos totales; pero aun en la hipótesis (fácilmente negada) de que costara más que el propietario, la sola existencia de una herramienta de software libre eficaz para una determinada función informática obligaría al Estado a usarla; no por imperio de este Proyecto de Ley, sino por los principios elementales que enumeramos al comienzo y que surgen de la esencia misma del Estado democrático de derecho.

Sigue Ud.: "6. Es equivocado pensar que el Software de Código Abierto es gratuito. Investigaciones realizadas por Gartner Group (importante investigadora del mercado tecnológico reconocida a nivel mundial) han señalado que el costo de adquisición del software (sistema operativo y aplicaciones) se reduce a sólo 8% del total de costos que las empresas e instituciones deben asumir como consecuencia del uso racional y realmente provechoso de la tecnología. El otro 92% lo constituyen: costos de implantación, capacitación, soporte, mantenimiento, administración e inoperatividad."

Este argumento repite lo ya señalado en el párrafo 5 y en parte se contradice con el párrafo 3. Por lo tanto nos remitiremos a lo allí dicho en homenaje a la brevedad. No obstante, permítame señalarle que incurre en una conclusión falsa en el plano lógico: que el costo de software según Gartner Group sea sólo el 8% en promedio del costo total de utilización, no invalida en forma alguna la existencia de software gratuito, esto es, aquel cuyo costo de licenciamiento es cero.

Además en este párrafo Ud. indica acertadamente que los componentes de servicio y las pérdidas por indisponibilidad conforman la parte sustancial del costo total de utilización de software; lo que, advertirá, entra en contradicción con su afirmación del valor mínimo de los servicios sugerido en el párrafo 3. Ahora bien, el empleo de software libre contribuye significativamente a disminuir los restantes costos del ciclo de vida. Esta reducción del impacto económico de despliegue, soporte, etc. se registra en varios campos; por un lado, el modelo competitivo de servicios del software libre, cuyo soporte y mantenimiento es posible contratar libremente entre una oferta variada que compite en función de la calidad y el menor costo. Esto es válido para la implantación, la capacitación y el soporte, y en buena medida para el mantenimiento. En segundo lugar, por la característica reproductiva del modelo, hace que el mantenimiento que se realizó en una aplicación sea replicable muy fácilmente, sin incurrir en mayores costos (es decir, sin pagar más de una vez por lo mismo) pues las modificaciones, si así se desea, quedan incorporadas al patrimonio común del conocimiento. En tercero, porque el enorme costo causado por la inoperatividad ("pantallas azules de la muerte", código malicioso como virus, worms y troyanos, excepciones, fallas generales de protección y otros tantos males conocidos) se reduce significativamente al emplear software mas estable; y es bien sabido que una de las virtudes mas destacables del software libre es su estabilidad.

Afirma luego que: "7. Uno de los argumentos que sustentan el proyecto de ley es la supuesta gratuidad del software de código abierto, comparado con los costos del software comercial, sin tener en cuenta que existen modalidades de licenciamiento por volumen que pueden ser sumamente ventajosas para el Estado, tal como se ha logrado en otros países."

He puntualizado ya que lo que está en cuestión no es el costo del software, sino los principios de libertad de información, accesibilidad y seguridad. Estos argumentos se han tratado de manera extensa en párrafos anteriores, por lo que estimaré remitirse a ellos.

Por otra parte, ciertamente existen modalidades de licenciamiento por volumen (aunque infortunadamente, el software propietario no satisface los principios básicos). Pero, como Ud. acaba de señalarlo acertadamente en el párrafo inmediatamente anterior de su carta, sólo apuntan a reducir el impacto de un componente que importa no más del 8% del costo total.

Prosigue: "8. Adicionalmente, la alternativa adoptada por el proyecto (i) es claramente más costosa por los altos costos que supone una migración y (ii) pone en riesgo la compatibilidad y posibilidad de interoperabilidad de las plataformas informáticas dentro del Estado, y entre el Estado y el sector privado, dada la centena de versiones que existen de software de código abierto en

el mercado."

Analicemos su afirmación en dos partes. Su primer argumento, el de que la migración supone altos costos es en realidad un argumento en favor del Proyecto. Porque cuanto más tiempo transcurra la migración a otra tecnología esta se tornará mas onerosa; y al mismo tiempo se irán incrementando los riesgos de seguridad asociados con el software propietario. De esta manera, el uso de sistemas y formatos propietarios va haciendo que el Estado se vuelva cada vez más dependiente de proveedores determinados. Por el contrario, una vez implantada la política de uso de software libre (implantación que, es cierto, implica un costo), la migración de un sistema a otro se hace muy sencilla, ya que todos los datos están almacenados en formatos abiertos. Por otra parte, la migración a un entorno de software abierto no implica más costos que la misma entre entornos distintos de software propietario, con lo que su argumento se invalida totalmente.

El segundo argumento refiere a "dificultades de interoperabilidad de las plataformas informáticas dentro del Estado, y entre el Estado y el sector privado". Esta afirmación implica un cierto desconocimiento de los mecanismos de construcción de software libre, en el que no se maximiza la dependencia del usuario respecto de una plataforma determinada, como sucede habitualmente en el campo del software propietario. Aun cuando existen múltiples distribuciones de software libre, y numerosos programas susceptibles de ser empleados para una misma función, la interoperabilidad queda garantizada tanto por el empleo de formatos estándar, exigido en el proyecto, como por la posibilidad de construir software interoperable a partir de la disponibilidad del código fuente.

Dice luego que: "9. El software de código abierto en su mayoría no ofrece los niveles de servicio adecuados ni la garantía de fabricantes reconocidos para lograr mayor productividad por parte de los usuarios, lo cual ha motivado que diferentes entidades públicas hayan retrocedido en su decisión de ir por una solución de software de código abierto y se encuentren utilizando software comercial en su lugar."

Esta observación es infundada. Respecto de la garantía su argumento ha sido rebatido respondiendo el párrafo 4. Respecto de los servicios de soporte, es posible usar software libre sin ellos (así como sucede también con el software propietario) pero quienes los requieran pueden adquirir soporte por separado, tanto de empresas locales cuanto de corporaciones internacionales, también como en el caso de software propietario.

Por otra parte, contribuiría en mucho a nuestro análisis que nos informase acerca de proyectos de software libre implantados en entidades públicas, que a la fecha hayan sido abandonados en favor del software propietario. Conocemos un buen número de casos en el sentido inverso, pero carecemos de información respecto de casos en el sentido que Ud. expone.

Continua observando que: "10. El proyecto desincentiva la creatividad de la industria peruana de software, que factura US$ 40 millones/año, exporta US$ 4 millones (10mo. en ranking productos de exportación no tradicional, más que artesanías) y es una fuente de empleo altamente calificado. Con una Ley que incentive el uso de software de código abierto, los programadores de software pierden sus derechos de propiedad intelectual y su principal fuente de retribución."

Esta claro por demás que nadie esta obligado a comercializar su código como software libre. Tan sólo deberá tener en cuenta que, si no lo hace, no podrá venderle al sector público. Este, por otra parte, no constituye el principal mercado para la industria nacional de software. Lineas arriba hemos abordado algunas cuestiones referidas a la influencia del Proyecto en la generación de empleo técnico altamente calificado y en mejores condiciones de competitividad, por lo que parece innecesario insistir aquí en el punto.

Lo que sigue en su afirmación es erróneo. Por un lado, ningún autor de software libre pierde sus derechos de propiedad intelectual, a menos que por su expresa voluntad desee colocar su obra en el dominio público. El movimiento del software libre siempre ha sido extremadamente respetuoso de la propiedad intelectual, y ha generado reconocimiento público extenso a los autores. Nombres como el de Richard Stallman, Linus Torvalds, Guido van Rossum, Larry Wall, Miguel de Icaza, Andrew Tridgell, Theo de Raadt, Andrea Arcangeli, Bruce Perens, Darren Reed, Alan Cox, Eric Raymond, y muchos otros, son mundialmente reconocidos por sus contribuciones en el desarrollo de software que hoy es utilizado por millones de personas en todo el mundo, en tanto los nombres de los autores materiales de excelentes piezas de software propietario, permanecen en el anonimato. Por otra parte, afirmar que las regalías por derechos de autor constituyen la principal fuente de retribución de los programadores Peruanos es en todo caso aventurado, en particular porque no se ha aportado ninguna prueba al efecto ni una demostración de como el empleo de software libre por el Estado influiría en esta retribuciones.

Prosigue Ud. diciendo que: "11. El software de código abierto, al poder ser distribuido gratuitamente, tampoco permite generar ingresos para sus desarrolladores por medio de la exportación. De esta forma, se debilita el efecto multiplicador de la venta de software a otros países y por lo tanto el crecimiento de esta industria, cuando contrariamente las normas de un Gobierno deben estimular la industria local."

Esta afirmación demuestra nuevamente un desconocimiento total de los mecanismos y el mercado del software libre. Intenta aseverar que el mercado de cesión de derechos no exclusivos de uso a titulo oneroso (venta de licencias) es el único posible para la industria informática cuando, como Ud. mismo lo ha señalado párrafos arriba, ni siquiera es el más importante. El incentivo que el proyecto presenta al surgimiento de una oferta de profesionales más calificados, en conjunto con el incremento de experiencia que resultará para los técnicos nacionales el trabajar a gran escala con software libre en el Estado, los colocan en una posición altamente competitiva para brindar sus servicios al extranjero.

Señala luego que "12. En el Foro se discutió sobre la importancia del uso de software de código abierto en la educación, sin comentar el rotundo fracaso de esta iniciativa en un país como México, en donde precisamente los funcionarios del Estado que fundamentaron el proyecto, hoy expresan que el software de código abierto no permitió brindar una experiencia de aprendizaje a alumnos en la escuela, no se contó con los niveles de capacitación a nivel nacional para dar soporte adecuado a la plataforma, y el software no contó y no cuenta con los niveles de integración para la plataforma que existen en las escuelas."

Efectivamente, en México se dio marcha atrás con el proyecto Red Escolar. Eso se debió, precisamente a que los impulsores del proyecto mexicano tuvieron al costo de las licencias como principal argumento, en vez de las otras razones estipuladas en nuestro proyecto y que son mucho más esenciales. Debido a este error conceptual, y como consecuencia de la falta de apoyo efectivo por parte de la SEP (Secretaria de Educación Publica) se asumió que para implementar software libre en las escuelas, bastaba con quitarle a éstas el presupuesto para software y en cambio enviarles un CD ROM con GNU/Linux. Por cierto, esto falló y no podía ser de otro modo, tal como fallan los laboratorios escolares en los que se usa software propietario si no hay presupuesto para implementación y mantenimiento. Es precisamente por eso que nuestro proyecto de ley no se limita a indicar la mandatoriedad del uso de software libre, sino que reconoce la necesidad y ordena la creación de un plan de migración viable, en el que el Estado encamine ordenadamente la transición técnica para lograr disfrutar de las ventajas del software libre.

Finaliza Ud. con una pregunta retórica: "13. Si el software de código abierto satisface todos lo requerimientos de las entidades del Estado ¿por que se requiere de una Ley para adoptarlo? ¿No debería ser el mercado el que decida libremente cuáles son los productos que le dan más beneficios o valor?".

Estamos de acuerdo que en el sector privado de la economía, es el mercado quien debe decidir que productos usar y allí no sería admisible ninguna intromisión estatal. Pero en el caso del sector público, el razonamiento no es el mismo: Como ya establecimos el Estado almacena, manipula y transforma información que no le pertenece, sino que la ha sido confiada por los ciudadanos que, por imperio de la ley, no tienen más alternativa que hacerlo. Como contraparte a esa imposición legal, el Estado debe extremar las medidas para salvaguardar la integridad, confidencialidad y accesibilidad de esa informaciones. El empleo de software propietario arroja serias dudas sobre el cumplimiento de estos atributos, a falta de evidencia concluyente al respecto y por lo tanto no es apto para ser usado en el sector público.

La necesidad de una ley estriba, por un lado, en la materialización de los principios fundamentales antes enunciados en el campo específico del software. Por otro, en el hecho de que el Estado no es una entidad ideal homogénea, sino que esta compuesto de múltiples organismos con diversos grados de autonomía de decisiones. Dado que el software propietario es inapropiado para ser empleado, el hecho de establecer estas reglas en la ley impediría que la decisión discrecional de cualquier funcionario ponga en riesgo la información que pertenece a los ciudadanos. Y, sobre todo, porque constituye una reafirmación actualizada en relación con los medios de tratamiento y comunicación de información empleados hoy en día, sobre el principio republicano de publicidad.

Conforme a este principio universalmente aceptado, el ciudadano tiene derecho a conocer toda información en poder del Estado que no esté amparada en una declaración fundada de secreto conforme a la ley. Ahora bien, el software trata información y es en sí mismo información. Información en formato especial, susceptible de ser interpretada por una máquina para ejecutar acciones, pero sin duda información crucial porque el ciudadano tiene legítimo derecho a saber, por ejemplo, como se computa su voto o se calculan sus impuestos. Y para ello, debe poder acceder libremente al código fuente y probar a su satisfacción los programas que se utilizan para el cómputo electoral o para el cálculo de sus impuestos.

Saludo a Ud. con las expresiones de mi mayor consideración, reiterando que mi despacho siempre estará abierto a que expongan sus puntos de vista al detalle que Ud. crea conveniente.

Atentamente,

DR. EDGAR DAVID VILLANUEVA NUÑEZ

Congresista de la República del Perú.

ANEXO III

CONSTITUIÇÃO DEBIAN

Disponível no site http://www.debian.org/. Acesso em 15/10/2004.

Versão 1.2 ratificada em 29 de outubro de 2003. Substitui a Versão 1.1 ratificada em 21 de junho de 2003, que substituiu a Versão 1.0 ratificada em 2 de Dezembro de 1998.

1. Introdução

O Projeto Debian é uma associação de indivíduos que têm a causa comum de criar um sistema operacional livre. Esse documento descreve a estrutura organizacional para tomadas de decisões formais no Projeto. Ele não descreve os objetivos do Projeto ou como alcança-los, nem contém quaisquer políticas exceto aquelas diretamente relacionadas ao processo de tomada de decisões. 2. Corpos e indivíduos na tomada de decisões

Cada decisão no Projeto é tomada por um ou mais dos seguintes:

  1. Os Desenvolvedores, por via de Resolução Geral ou votação;
  2. O Líder do Projeto;
  3. O Comitê Técnico e/ou seu Líder;
  4. O Desenvolvedor particular trabalhando em uma tarefa particular;
  5. Delegados apontados pelo Líder do Projeto para tarefas específicas;
  6. O Secretário do Projeto.
A maior parte do restante desse documento irá descrever os poderes desses corpos, sua composição e nomeação e o procedimento para suas tomadas de decisões. Os poderes de uma pessoa ou corpo pode estar sujeito a revisão e/ou limitação por outros; nesse caso o corpo revisor ou a a entrada da pessoa irá mostrar isso. Na lista acima, uma pessoa ou corpo é normalmente listado antes de quaisquer pessoas ou corpos cujas tomadas de decisões podem ser anuladas por este ou aqueles que eles (ajudam a) nomeiam - mas nem todos os listados no início podem anular a todos listados ao fim.

2.1. Regras Gerais

1.Nada nessa constituição impõe uma obrigação a alguém de trabalhar para o Projeto. Uma pessoa que não quer trabalhar em uma tarefa a que foi designada ou delegada a ela não precisa executá-la. No entanto, elas não podem trabalhar ativamente contra essas regras e decisões tomadas propriamente sob elas.

2.Uma pessoa pode ter vários cargos, exceto que o Líder do Projeto, o Secretário do Projeto e o Líder do Comitê Técnico devem ser distintos e que o Líder não pode nomear estes como seus Delegados.

3.Uma pessoa pode deixar o Projeto ou renunciar de um cargo em particular que possua a qualquer momento, fazendo isso publicamente.

3. Desenvolvedores Individuais

3.1. Poderes

Um Desenvolvedor Individual pode

1.tomar qualquer decisão técnica ou não-técnica no que diz respeito a seu próprio trabalho;

2.propor ou apadrinhar rascunhos de Resoluções Gerais;

3.propor a sí mesmo como candidato a Líder do Projeto nas eleições;

4.votar em Resoluções Gerais e em eleições para Líder.

3.2. Composição e nomeação

1.Desenvolvedores são voluntários que concordam com os objetivos futuros do Projeto como participantes dele e que mantém pacotes para o Projeto ou fazem algum outro trabalho que seja considerado importante pelo(s) Delegado(s) do Líder do Projeto.

2.O(s) Delegado(s) do Líder do Projeto podem escolher não admitir novos Desenvolvedores ou expelir Desenvolvedores existentes. Se os Desenvolvedores acham que os Delegados estão abusando de sua autoridade eles podem, é claro, anular a decisão por meio de uma Resolução Geral - veja §4.1(3), §4.2.

3.3. Procedimento

Desenvolvedores podem tomar decisões quando eles acharem conveniente.

4. Os Desenvolvedores por meio de uma Resolução Geral ou Votação

4.1. Poderes

Juntos, os Desenvolvedores podem:

1.Nomear ou reeleger o Líder do Projeto.

2.Emendar esta constituição, desde que concordem com maioria de 3:1.

3.Anular qualquer decisão tomada pelo Líder do Projeto ou por um Delegado.

4.Anular qualquer decisão tomada pelo Comitê Técnico, desde que concordem com maioria de 2:1.

5.Criar, substituir e retirar documentos e declarações de políticas não-técnicas. Esses incluem documentos descrevendo os objetivos do projeto, sua relação com outras entidades de software livre e políticas não-técnicas como termos de licença de software livre com os quais o software no Debian deve concordar. Eles podem também incluir declarações sobre posicionamente sobre assuntos do dia.

1.Um Documento Fundamental é um documento ou declaração considerada crítica à missão e aos propósitos do Projeto.

2.Os Documentos Fundamentais são os trabalhos entitulados Contrato Social Debian e Definição Debian de Software Livre.

3.Um Documento Fundamental requer uma maioridade de 3:1 para sua substituição. Documentos Fundamentais novos são criados e os existentes são retirados alterando a lista de Documentos Fundamentais nesta constituição.

6.Juntos com o Líder do Projeto e o SPI, tomar decisões sobre propriedades guardadas em confiança para propósitos relacionados ao Debian. (Veja §9.1.)

4.2. Procedimento

1.Os desenvolvedores seguem o Procedimento de Resolução Padrão, abaixo. Uma resolução ou emenda é introduzida se proposta por qualquer Desenvolvedor e apadrinhada por pelo menos K outros Desenvolvedores, ou se proposta pelo Líder do Projeto ou pelo Comitê Técnico.

2.Adiando uma decisão tomada pelo Líder do Projeto ou seu Delegado:

1.Se o Líder do Projeto, ou seu Delegado, ou o Comitê Técnico tomou uma decisão, então os Desenvolvedores podem anulá-la passando uma resolução para tal; veja s4.1(3).

2.Se tal resolução for apadrinhada por pelo menos 2K Desenvolvedores, ou se for proposta pelo Comitê Técnico, a resolução adia a decisão imediatamente (desde que a resolução diga isso).

3.Se a decisão original foi para mudar um período de discussão ou um período de votação, ou a resolução é para anular o Comitê Técnico, então apenas K Desenvolvedores precisam apadrinhar a resolução para que a decisão seja adiada.

4.Se a decisão é adiada, uma votação imediata acontece para determinar se a decisão deve continuar até que a votação completa seja feita ou se a implementação da decisão original será adiada até lá. Não há quorum para esse procedimento de votação imediata.

5.Se o Líder do Projeto (ou o Delegado) retira a decisão original a votação se torna um debate e não é mais conduzida.

3.Votações são organizadas pelo Secretário do Projeto. Votos, estimativas e resultados não serão revelados durante o período de votação; depois da votação o Secretário do Projeto lista todos os votos. O período de votação é de 2 semanas mas pode ser variado em até 1 semana pelo Líder do Projeto.

4.O período de discussão mínimo é de 2 semanas mas pode ser variado em até uma semana pelo Líder do Projeto. O Líder do Projeto tem o voto de minerva. Há um quorum de 3Q.

5.Propostas, padrinhos, emendas, chamadas para a votação e outras ações formais são feitas anunciando em uma lista de discussão publicamente legível designada pelo(s) Delegado(s) do Líder do Projeto; qualquer Desenvolvedor pode postar lá.

6.Os votos são enviados por email em uma maneira que convenha ao Secretário. O Secretário determina para cada votação se os votantes podem trocar seus votos ou não.

7.Q é a metade da raiz quadrada do número atual de Desenvolvedores. K é Q ou 5, o que for menor. Q e K não precisam ser inteiros e não são arredondados.

5. Líder do Projeto

5.1. Poderes

O Líder do Projeto pode:

1.Nomear Delegados ou delegar decisões ao Comitê Técnico.

O Líder pode definir uma área de responsabilidade ou uma decisão específica e passá-la a qualquer outro desenvolvedor ou ao Comitê Técnico. Uma vez que uma decisão particular tenha sido delegada e tomada o Líder do Projeto não pode voltar atrás na delegação; no entanto ele pode voltar atrás em uma delegação corrente de uma área de responsabilidade particular.

2.Emprestar autoridade a outros Desenvolvedores.

O Líder do Projeto pode criar declarações de suporte para pontos de vista ou para outros membros do projeto, quando requisitado ou não; essas declarações tem força se e apenas se o Líder possuir poderes para tomar a decisão em questão.

3.Tomar decisões que requeiram ação urgente.

Isso não se aplica a decisões que se tornaram gradualmente urgentes pela falta de ação relevante a menos que haja um prazo fixado.

4.Tomar decisões para as quais ninguém mais tem responsabilidade.

5.Propor rascunhos de Resoluções Gerais e emendas.

6.Juntamente com o Comitê Técnico, nomear novos membros para o Comitê. (Veja §6.2.)

7.Usar um voto de minerva quando os Desenvolvedores votam.

O Líder do Projeto têm também um voto normal em tais votações.

8.Alterar o período de discussões para votações dos Desenvolvedores (como acima).

9.Liderar discussões entre os Desenvolvedores.

O Líder do Projeto deve tentar tomar parte em discussões entre os Desenvolvedores de uma maneira que ajude e traga as discussões ao assunto chave. O Líder do Projeto não deve usar sua posição de liderança para promover seus próprios pontos de vista.

10.Juntamente com o SPI, tomar decisões que afetem a propriedade guardada em confiança para propósitos relacionados ao Debian. (Veja §9.1.)

5.2. Nomeação

1.O Líder do Projeto é eleito pelos Desenvolvedores.

2.A eleição começa nove semanas antes do posto de liderança ficar vago ou (se já é muito tarde) imediatamente.

3.Pelas três semanas seguintes qualquer Desenvolvedor pode nomear a si mesmo como um candidato a Líder do Projeto.

4.Pelas próximas três semanas nenhum candidato pode ser nomeado; os candidatos devem usar esse tempo para fazer campanha (para tornar suas identidades e posições conhecidas). Se não há candidatos ao fim do período de nomeação então o período de nomeação é extendido pelas três semanas seguintes, repetidamente se necessário.

5.As próximas três semanas são o período de eleição durante o qual os Desenvolvedores podem enviar seus votos. Votos nas eleições de liderança são mantidos em segredo, mesmo após o término das eleições.

6.As opções das cédulas serão aqueles candidatos que se nomearam e não desistiram ainda, mais Nenhum Dos Acima. Se Nenhum Dos Acima ganhar a eleição então o procedimento de eleição é repetido, muitas vezes se necessário.

7.A decisão será tomada usando o método especificado na seção §A.6 do Procedimento de Resolução Padrão. O quorum é o mesmo que o usado em Resoluções Gerais (§4.2) e a opção padrão é Nenhum Dos Acima.

8.O Líder do Projeto serve por um ano a partir de sua eleição.

5.3. Procedimento

O Líder do Projeto deve tentar tomar decisões que são consistentes com o consenso das opiniões dos Desenvolvedores.

Onde couber, o Líder do Projeto deve informalmente solicitar os pontos de vista dos Desenvolvedores.

O Líder do Projeto deve evitar que seu ponto de vista sobressaia quando for tomar decisões em sua capacidade de Líder.

6. Comitê Técnico

6.1. Poderes

O Comitê Técnico pode:

1.Decidir em qualquer problema de política técnica.

Isso inclui o conteúdo dos manuais de políticas técnicas, materiais de referência dos desenvolvedores, pacotes de exemplo e o comportamento das ferramentas de construção de pacotes não experimentais. (Em cada caso o mantenedor normal do programa relevante ou da documentação toma as decisões inicialmente, no entanto; veja 6.3(5).)

2.Decidir qualquer assunto técnico onde há sobreposição da jurisdição dos Desenvolvedores.

Em casos onde os Desenvolvedores precisam implementar políticas técnicas ou locais (por exemplo, se eles não concordam sobre as prioridades de pacotes conflitantes ou sobre o dono de um nome de comando ou sobre qual pacote é responsável por um erro que ambos os mantenedores concordam ser um erro) o comitê técnico pode decidir o problema.

3.Tomar uma decisão quando requisitado para tal.

Qualquer pessoa ou corpo pode delegar uma decisão própria ao Comitê Técnico ou procurar aconselhamento com ele.

4.Sobrepujar um Desenvolvedor (requer uma maioria de 3:1).

O Comitê Técnico pode pedir a um Desenvolvedor para tomar um curso de ação técnica particular mesmo que o Desenvolvedor não queira; isso requer uma maioria de 3:1. Por exemplo, o Comitê pode determinar que uma reclamação feita pelo emissor de um erro é justificada e que a solução proposta pelo emissor deve ser implementada.

5.Oferecer conselhos.

O Comitê Técnico pode fazer anúncios formais sobre seus pontos de vista sobre qualquer problema. Membros individuais podem, é claro, criar declarações informais sobre seus pontos de vista e sobre os prováveis pontos do Comitê.

6.Juntamente com o Líder do Projeto, nomear novos membros para si ou remover membros existentes. (Veja §6.2.)

7.Nomear o Líder do Comitê Técnico.

O Líder é eleito pelo Comitê, entre seus membros. Todos os membros do comitê estão automáticamente nomeados; o comitê começa a votar com uma semana faltando para que o posto fique vago (ou imediatamente se já é muito tarde). Os membros podem votar por aclamação pública em qualquer colega membro do comitê, incluindo a si mesmos; não há opção padrão. A votação acaba quando todos os membros votaram ou quando o período de votos estiver terminado. O resultado é determinado usando o método especificado na seção A.6 do Procedimento de Resolução Padrão..

8.O Líder do Comitê pode servir de Líder do Projeto, juntamente com o Secretário Como detalhado em §7.1(2), o Líder do Comitê Técnico e o Secretário do Projeto podem, juntos, servirem como Líderes do Projeto se não houver Líder.

6.2. Composição

1.O Comitê Técnico consiste em até 8 Desenvolvedores e normalmente deve ter pelo menos 4 membros.

2.Quando há menos de 8 membros o Comitê Técnico pode recomendar membros novos ao Líder do Projeto, que pode escolher (indivualmente) nomeá-los ou não.

3.Quando houver 5 membros ou menos o Comitê Técnico pode nomear membros novos até que o número de membros atinja 6.

4.Quando houver 5 membros ou menos por pelo menos uma semana o Líder do Projeto pode nomear novos membros até que o número de membros atinja 6, em intervalos de pelo menos uma semana por nomeação.

5.Se o Comitê Técnico e o Líder do Projeto concordarem, eles podem remover ou substituir um membro existente do Comitê Técnico.

6.3. Procedimento

1.O Comitê Técnico usa o Procedimento Padrão de Resolução.

Um rascunho de resolução ou emenda pode ser proposto por qualquer membro do Comitê Técnico. Não há período de discussão mínimo; o período de votação dura por uma semana ou até que o resultado não seja mais duvidoso. Os membros podem mudar seus votos. Há um quorum de dois.

2.Detalhes relacionados à votação

O Líder tem um voto de minerva. Quando o Comitê Técnico vota para sobrepujar um Desenvolvedor que também é membro do Comitê, esse membro não pode votar (a menos que seja o Líder, nesse caso ele pode usar apenas seu voto de minerva).

3.Discussão Pública e tomada de decisões.

Discussão, rascunhos de resoluções e emendas e votos dos membros do comitê são feitos publicamente na lista de discussão do Comitê Técnico. Não há secretário separado para o Comitê.

4.Nomeações Confidenciais.

O Comitê Técnico pode manter discussões confidenciais via email privado ou lista de discussão privada ou outros meios para discutir nomeações para o Comitê. No entanto, as votações para as nomeações devem ser públicas.

5.Não criar trabalhos de desing detalhados.

O Comitê Técnico não entra no desenho de novas propostas e políticas. Tal trabalho deve ser conduzido por indivíduos privadamente ou junto com outros e discutido em fóruns ordinários de design e políticas técnicas.

O Comitê Técnico restringe a si escolher ou adotar compromissos entre soluções e decisões que foram propostas e razoavelmente discutidas em outros lugares. Membros individuais do comitê técnico podem, é claro, participar por si mesmos no trabalho de design e políticas.

6.O Comitê Técnico toma decisões apenas como último recurso.

O Comitê Técnico não toma uma decisão técnica até que esforços para se resolver a questão via consenso tenham sido feitos e falhado a menos que ele tenha sido solicitado para tomar uma decisão pela pessoa ou corpo que seria normalmente responsável por ela.

7. O Secretário do Projeto

7.1. Poderes

O Secretário:

1.Pega os votos entre os Desenvolvedores e determina o número e a identidade dos Desenvolvedores, sempre que requerido por essa constituição.

2.Pode servir de Líder do Projeto, junto com o Líder do Comitê Técnico. Se não há Líder do Projeto então o Líder do Comitê Técnico e o Secretário do Projeto podem por concordância tomar decisões se eles considerarem isso imperativo.

3.Resolve qualquer disputa sobre a interpretação da constituição.

4.Pode delegar parte ou toda a sua autoridade para alguém ou desistir dessa delegação a qualquer momento.

7.2. Nomeação

O Secretário do Projeto é nomeado pelo Líder do Projeto e pelo Secretário atual do Projeto.

Se o Líder do Projeto e o Secretário do Projeto atuais não podem concordar em uma nova nomeação eles devem solicitar à bancada do SPI (veja §9.1.) para nomear um Secretário.

Se não há Secretário do Projeto ou o Secretário atual está indisponível e não delegou autoridade para uma decisão, então a decisão pode ser tomada ou delegada pelo Líder do Comitê Técnico, como Secretário Agente.

O mandato do Secretário do Projeto é de 1 ano, depois do qual ele ou outro Secretário deve ser (re)nomeado.

7.3. Procedimento

O Secretário do Projeto deve tomar decisões que são bem razoaveis e preferívelmente consistentes com o consenso dos Desenvolvedores.

Quando agindo conjuntamente como Líderes do Projeto o Líder do Comitê Técnico e o Secretário do Projeto devem tomar decisões somente quando absolutamente necessárias e somente quando consistentes com o consenso dos Desenvolvedores.

8. Os Delegados do Líder do Projeto

8.1. Poderes

Os Delegados do Líder do Projeto:

1.tem poderes delegados a eles pelo Líder do Projeto;

2.podem tomar certas decisões que o Líder não pode tomar diretamente, incluindo aprovação ou removeção de Desenvolvedores ou designação de pessoas como Desenvolvedores que não mantém pacotes. Isso é para evitar concentração de poder, particularmente sobre a entrada de Desenvolvedores, nas mãos do Líder do Projeto.

8.2. Nomeação

Os Delegados são nomeados pelo Líder do Projeto e podem ser substituídos pelo Líder a seu critério. O Líder do Projeto não pode dar a posição de Delegado com condições sobre decisões particulares do Delegado nem pode anular uma decisão tomada por um Delegado uma vez que esteja tomada.

8.3. Procedimento

Os Delegados podem tomar decisões como acharem melhor mas devem tentar implementar decisões técnicas boas e/ou seguir a opinião do consenso.

9. Software in the Public Interest

O SPI e o Debian são organizações separadas que compartilham alguns objetivos. O Debian é grato pelo suporte legal oferecido pelo SPI. Os Desenvolvedores do Debian são atualmente membros do SPI em virtude do seu status de Desenvolvedores.

9.1. Autoridade

1.O SPI não tem autoridade relativa a decisões técnicas ou não-técnicas do Debian, exceto que nenhuma decisão do Debian com respeito a qualquer propriedade guardada pelo SPI deve requerer que o SPI haja fora de sua autoridade legal e que a constituição do Debian pode ocasionalmente usar o SPI como um corpo de decisão em último recurso.

2.O Debian não reivindica nenhuma autoridade sobre o SPI a não ser sobre o uso de algumas das propriedades do SPI, descritas abaixo, apesar de os Desenvolvedores Debian terem autoridade dentro do SPI de acordo com as regras do SPI.

3.Os Desenvolvedores Debian não são agentes ou empregados do SPI ou vice-versa, nem de pessoas de autoridade no Projeto Debian. Uma pessoa agindo como um Desenvolvedor o faz como um indivíduo em seu próprio nome.

9.2. Gerenciamento de propriedades para propósitos relacionados ao Debian

Já que o Debian não tem autoridade para guardar dinheiro ou propriedades, qualquer doação para o Projeto Debian deve ser feita ao SPI, que gerencia tais negócios. O SPI tem as seguintes incumbências:

1.O SPI irá guardar dinheiro, marcas e outras propriedades tangíveis ou intangíveis e gerenciar outros negócios para propósitos relacionados ao Debian.

2.Tal propriedade será contabilizada separadamente e guardada em confiança para esses propósitos, decididos pelo Debian e pelo SPI de acordo com essa seção.

3.O SPI não irá dispor ou usar propriedade guardada em confiança para o Debian sem aprovação do Debian, que pode ser dada pelo Líder do Projeto ou por Resolução Geral dos Desenvolvedores.

4.O SPI considerará usar ou dispor de propriedade guardada em confiança para o Debian quando requisitada a fazer tal pelo Líder do Projeto.

5.O SPI usará ou disporá de propriedade guardada em confiança para o Debian quando requisitado a fazê-lo por Resolução Geral dos Desenvolvedores, dado que isso seja compatível com a autoridade legal do SPI.

6.O SPI notificará os Desenvolvedores por correio eletrônico para uma lista de discussão do Projeto Debian quando ele usar ou dispor de propriedade guardada em confiança para o Debian.

A. Procedimento Padrão para Resolução Essas regras aplicam-se a tomadas de decisões comunais por comitês e plebiscitos, onde colocado acima.

A.1. Proposta

O procedimento formal começa quando um rascunho de resolução é proposto e apadrinhado, como requerido.

A.1. Discussão e Emendamento

1.Seguindo a proposta, a resolução pode ser discutida. Emendas devem ser tornadas formais sendo propostas e apadrinhadas de acordo com os requerimentos para uma nova resolução ou diretamente pelo proponente da resolução original.

2.Um emendamento formal pode ser aceito pelo proponente da resolução em cujo caso o rascunho da resolução formal é imediamente alterado para igualar-se.

3.Se um emendamento formal não é aceito ou um dos padrinhos da resolução não concordam com a aceitação pelo proponente de um emendamento formal, o emendamento continua como um emendamento e será votado.

4.Se um emendamento aceito pelo proponente original não é do gosto dos outros, eles podem propor outra emenda para reverter a mudança feita anteriormente (novamente, eles precisam atingir os requerimentos para proponente e padrinho(s).)

5.O proponente ou uma resolução pode sugerir mudanças para os dizeres dos emendamentos; esses tomam efeito se o proponente do emendamento concordar e nenhum dos padrinhos objetarem. Nesse caso o emendamento mudado será votado ao invés dos originais

6.O proponente de uma resolução pode fazer mudanças para correção de erros pequenos (por exemplo erros tipográficos ou inconsistências) ou mudanças que não alteram o significado, desde que ninguém objete dentro de 24 horas. Nesse caso o período de discussão mínimo não é reiniciado.

A.2. Chamada para votação

1.O proponente ou um padrinho de uma moção ou uma emenda pode chamar para uma votação, desde que o período de discussão mínimo (se houver) tiver terminado.

2.O proponente ou qualquer padrinho de uma resolução podem chamar para uma votação naquela resolução e todas as emendas relacionadas.

3.A pessoa que chama para uma votação diz o que acha que os dizeres da resolução e quaisquer emendas relevantes devam ser e, consequentemente a forma que a votação deve tomar. No entanto, a decisão final na forma da(s) votação(ões) é do Secretário - veja 7.1(1), 7.1(3) e A.3(4).

4.O período de discussão mínimo é contado a partir do momento em que a última emenda é aceita ou do momento que a resolução completa foi proposta se nenhuma emenda foi proposta e aceita.

A.3. Procedimento de Votação

1.Cada resolução e suas emendas relacionadas são votadas em uma única cédula que incluí uma opção para a resolução original, cada emenda, e a opção padrão (aonde aplicável).

2.A opção padrão não deve ter nenhum requerimento de supermaioridade. Opções que não tiverem um requerimento explícito de supermaioridade tem um requerimento de maioridade 1:1.

3.Os votos são contados de acordo com as regras em A.6. A opção padrão é "Mais Discussões", a não ser que outra seja especificada.

4.Em casos de dúvida, o Secretário do Projeto decidirá as questões de procedimento. A.4. Retirando resoluções ou emendas não aceitas

O proponente de uma resolução ou emenda não aceita pode retirá-la. Nesse caso novos proponentes podem vir e mantê-la viva, a primeira pessoa a fazê-lo torna-se o novo proponente e quaisquer outros se tornam padrinhos se já não o são. Um padrinho de uma resolução ou emenda (a menos que ela tenha sido aceita) pode retirá-la.

Se a retirada do proponente e/ou padrinhos significa que uma resolução não tem proponente ou padrinhos o suficiente ela não será votada a menos que isso seja retificado antes do vencimento da resolução.

A.5. Vencimento

Se uma resolução proposta não foi discutida, emendada, votada ou de outra forma manejada por 4 semanas, o Secretário pode avisar que a questão está sendo retirada. Se nenhum dos padrinhos de qulquer um dos proponentes discordar durante 1 semana, a questão é retirada. O Secretário também pode incluir sugestões de como proceder, se apropriado.

A.6. Contagem de Votos

1.A cédula de cada votante gradua as opções que estão sendo votadas. Nem todas as opções precisam ser graduadas. Opções graduadas são consideradas preferidas em relação às não-graduadas. Votantes podem graduar opções igualmente. Opções não graduadas são consideradas como graduadas igualmente entre si. Detalhes de como as cédulas podem ser preenchidas serão incluídas na Chamada para Votos.

2.Se a votação tiver um requerimento de quorum R qualquer opção que não seja a padrão que não receber pelo menos R votos graduando aquela opção acima da padrão é desconsiderada.

3.Qualquer opção (não padrão) que não vencer a opção padrão na sua proporção requerida de maioridade é desconsiderada.

1.Dadas duas opções A e B, V(A,B) é o número de votantes que preferem a opção A sobre a B.

2.Uma opção A vence a opção padrão D por uma proporção de maioridade N se V(A,D) for estritamente maior que N * V(D,A).

3.Se uma supermaioridade de S:1 é requerida por A, sua proporção de maioridade é S; caso contrário, sua proporção de maioridade é 1.

4.Da lista de opções consideradas, nós geramos uma lista de vitórias em pares.

1.Uma opção A vence uma opção B se V(A,B) for estritamente maior que V(B,A)

5.Da lista de vitórias em pares [não desconsideradas], nós geramos um conjunto de vitórias transitivas.

1.Uma opção A vence transitivamente uma opção C se A vencer C ou se há alguma outra opção B aonde A vence B E B vence C transitivamente.

6.Nós construímos o conjunto Schwartz do conjunto de vitórias transitivas.

1.Uma opção A está no conjunt Schwartz se para todas as opções B, A vence transitivamente de B ou B não vence transitivamente A.

7.Se houverem vitórias entre opções no conjunto Schwartz, nós removemos a mais fraca destas vitórias da lista de vitórias em pares, e retornamos para o passo 5.

1.Uma vitória (A,X) é mais fraca que uma vitória (B,Y) se V(A,X) for menor que V(B,Y). (A,X) também é mais fraca que (B,Y) se V(A,X) for igual a V(B,Y) e V(X,A) for maior que V(Y,B).

2.A vitória mais fraca é aquela que não possuí uma vitória mais fraca que ela. Pode haver mais que uma destas vitórias.

8.Se não houverem vitórias dentro do conjunto Schwartz, então o vencedor é escolhido das opções do conjunto Schwartz. Se houver apenas uma dessas opções, esta é a vencedora. Se houverem múltiplas opções, o eleitor com o voto dado escolhe qual das opções ganha. Nota: Opções que os votantes graduam acima da opção padrão são opções que eles acham aceitáveis. Opções graduadas abaixo da opção padrão são opções que eles acham inaceitáveis.

Quando o Procedimento Padrão de Resolução vai ser usado, o texto que se refere a ela deve especificar o que é suficiente para se ter um rascunho de resolução proposto e/ou apadrinhado, qual o período de discussão mínimo e qual o período mínimo de votação. Deve também especificar qualquer supermaioria e/ou quorum (e opção padrão) a ser usado.

B. Uso de linguagem e tipografia

O presente do indicativo ('é', por exemplo) significa que a declaração é uma regra nessa constituição. `Pode' indica que a pessoa ou corpo tem prudência. `Deve' significa que será considerado uma boa coisa se a sentença for obedecida, mas esta não é obrigatória. Texto marcado como citação, como esse, é um raciocínio e não é parte da constituição. Ele deve ser usado apenas para ajudar na interpretação em casos duvidosos.

Topic revision: r1 - 08 Nov 2005 - 00:43:42 - CarlinhosCecconi
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki-SL? Send feedback