• PlanoNacionalDeComprasElectrónicasRequestForInformation

Nota: esta página é um documento em construção. O prazo limite é hoje.

Contexto

A ANSOL - Associação Nacional para o Software Livre - apresenta, desta forma, o seu contributo para o Programa Nacional de Compras Electrónicas (PNCE). Vemos, neste processo, a oportunidade de efectivamente abrir o mercado de software para a Administração Pública Central, que se tem encontrado fechado durante a última década no que toca a software livre. Vemos também a possibilidade de agilizar as compras da Administração Pública de uma forma que poderá ser benéfica quer para os fornecedores e compradores. Por isso, não podíamos deixar de contribuir para esta excelente iniciativa.

A visão do PNCE é [1]:

• A utilização de meios electrónicos no processo aquisitivo público (compras electrónicas) irá gerar poupanças estruturais e ganhos de eficiência nas compras do Estado, aumentar a transparência e a qualidade de serviço prestado pelo Estado, e facilitar e alargar o acesso das empresas, grandes e pequenas, ao mercado das compras públicas.

Esta visão toca na maior parte dos problemas que estão na origem das dificuldades da compra de software livre por parte da administração pública. Este documento vai apresentar os comentários e propostas que nos foram pedidos na reunião de 2 de Fevereiro e propostas para processos de aquisição que não discriminam, directa ou indirectamente, contra software livre.

O objectivo desta fase do processo do PNCE é identificar modelos de aquisição e pricing que permitam a inclusão de centenas ou milhares de fornecedores num único sistema de uma forma que seja útil para os seus utilizadores (os responsáveis de compras da administração pública).

Caracterização do PNCE

Esta secção apresenta a visão que temos actualmente do PNCE em termos de impacto.

O PNCE tentará agilizar um conjunto de compras, reduzindo a burocracia em compras acima dos €4.987,97[2] em várias categorias. Essa redução de burocracia é conseguida à custa da eliminação da obrigatoriedade de obter várias propostas concorrentes, se a aquisição fôr feita através da Agência Nacional de Compras Públicas (ANCP). Para evitar o aumento de custos inerente a uma redução da oferta (uma vez que nem todas as empresas que participariam numa consulta prévia participarão num concurso público internacional), o PNCE aposta na obtenção de economias de escala através da agregação das compras de vários ministérios para produtos que são necessários por todos eles.

Do nosso ponto de vista, os principais riscos que podem afectar o sucesso do PNCE são:

• Redução da oferta a um grupo muito limitado de fornecedores que serão os únicos capazes de dar resposta às necessidades agregadas de todos os compradores, resultando num aumento de preços por redução da capacidade de negociação.
• Eliminação de fornecedores devido aos requisitos burocráticos de acesso ao sistema do PNCE, reduzindo a oferta.

• Eliminação de determinados produtos/serviços que não se encaixam nos modelos de pricing adoptado, sendo, na prática, eliminadas da procura, reduzindo a oferta.

• Eliminação de reaproveitamento de soluções já adoptadas, ou adoptáveis a baixo custo (através da utilização de recursos temporais disponíveis).
• Redução da concorrência em cada concurso devido a grandes restrições de acesso aos cadernos de encargos.

A nossa opinião sobre como estes riscos podem ser colmatados para se atingir a visão o mais eficazmente possível encontram-se nas respostas dadas às perguntas, e em alguns apontamentos após as respostas dadas.

Respostas às questões colocadas

Categorização do software base a incluir no CPA

Proposta de categorização (árvore) do software base a incluir no CPA orientada às necessidades da AP, caracterizando-a sumariamente:

Utilizar o Software Map da Sourceforge como base para definição de categorias, subcategorias e produtos: http://sourceforge.net/softwaremap/. Este sistema tem classificados mais de 70 000 projectos de software e está em utilização há vários anos com pequena variação.

Em relação a esta categorização gostávamos de deixar duas sugestões:

• Não assumam a categorização como estática. Haverá sempre ajustes necessários, em particular nos primeiros meses. Garantam que existe uma forma de dar sugestões e, preferencialmente, um forum onde seja possível discutir a classificação.
• Permitir que um produto esteja em várias subcategorias. Nos casos em que não existe um produto que corresponda aos requisitos numa determinada subcategoria, o processo consiste em consultar todos os fornecedores dessa subcategoria. De forma a evitar reduzir de forma articial a oferta, recomendamos que cada produto possa ter uma ou mais subcategorias. Em termos de interface do catálogo, o produto apareceria em cada subcategoria quando se pedir para ser listada.

Proposta de categorização (árvore) do software base a incluir no CPA orientada às necessidades da AP, caracterizando-a com os respectivos requisitos (próprios da AP (ie. POCAL), do mercado, internacionais, de Interoperabilidade, normas/standards do mercado (OpenDocumentFormat - ISO/IEC 26300, XML,... ), certificações, ...

O mínimo que consideramos que qualquer oferta à administração pública deve ter em termos de software são:

1. Garantia que alguém poderá dar suporte dentro do tempo de vida expectável da aplicação.
2. Cumprimento de requisitos legais de funcionamento.
3. Possibilidade de fazer auditorias de segurança à funcionalidade da aplicação.
4. Possibilidade de exportação de dados num formato documentado e legível.
5. Possibilidade de guardar o estado da aplicação e recuperá-lo noutra máquina.

Além disso, devem ser consideradas como preferenciais:

1. Utilização de normas abertas (isto garante a interoperabilidade e aumenta a concorrência ao facilitar a implementação de soluções concorrentes).

Garantia de suporte

Existem dois tipos de garantias que podem ser dadas pelos fornecedores em relação a suporte de uma aplicação: independência do fornecedor ou garantia de continuidade do produto e do fornecedor original.

A independência do fornecedor é dada quando, em conjunto com o produto, é fornecido o código-fonte, a licença e os requisitos necessários para modificar e compilar o código e a licença do software permite a utilização de uma versão modificada. Desta forma, qualquer elemento da administração pública pode dar o suporte necessário, contratá-lo fora da administração pública ou mesmo através de um protocolo com universidades. Seria desejável que o produto modificado pudesse ser distribuído por, pelo menos as outras entidades da administração pública que tenham licenças do software.

A garantia de continuidade do produto consiste no tempo de vida do produto durante o qual o fornecedor se compromete a fornecer correcção de bugs de segurança. A garantia de continuidade do fornecedor consiste no conjunto de indicadores indirectos (volume de negócios, número de anos no mercado, rentabilidade financeira) que levem a crer que o fornecedor poderá atingir o tempo de vida do produto.

No caso de o fornecedor directo não ter a capacidade legal e/ou técnica para garantir o suporte, a garantia de fornecedor aplica-se também à entidade que detém essa capacidade e que o fornecedor está a representar.

Cumprimento de requisitos legais de funcionamento

Estes requisitos irão depender de categoria e subcategoria, mas também da utilização. Não é aceitável a utilização de um sistema operativo em máquinas para serviços públicos quando a licença destas quando uma empresa o pode desligar remotamente sem autorização do cliente[3]. Qualquer software adquirido deve garantir como mínimo a liberdade de uso durante o tempo de vida esperado da aplicação, sem quaisquer restrições ao uso ou ao conteúdo deste.

Auditorias de Segurança

Qualquer software adquirido deve permitir e facilitar (na licença e na prática) a análise do seu funcionamento de forma a garantir a segurança, privacidade e controlo dos dados, evitar fugas de informação indesejáveis e permitir a avaliação destas características por entidades externas reputáveis.

Exportação de Dados

Qualquer software adquirido deve incluir a funcionalidade de exportação dos dados para um formato documentado e legível. Preferencialmente deve ser utilizado uma norma internacional, quando existente. Na ausência desta funcionalidade, o fornecedor deve incluir no fornecimento tais ferramentas.

Quando existentes devem ser seguidas as directrizes da entidade responsável pelos arquivos nacionais: a Torre do Tombo.

Salvaguarda do estado da aplicação

Qualquer software adquirido deve integrar a funcionalidade de salvaguardar o estado da aplicação (vulgos backups) de forma a permitir uma recuperação posterior.

Normas abertas

Deve ser dada preferência a aplicações que usem normas abertas no maior número de pontos de contactos com o exterior possível. Uma norma aberta é qualquer norma que inclua os seguintes requisitos:

• Documentação técnica sem restrições de distribuição e cópia.
• Sem limitações legais à sua implementação, ou seja Royalty-Free (RF)[3]. Reasonable And Non-Discrimnatory (RAND) não é aceitável por discriminar contra software livre.
• Pelo menos duas implementações interoperáveis realizadas por entidades diferentes.

Para além de criar mercados (ao permitir a implementação de produtos concorrentes que podem substituir outros), a utilização de normas abertas permite ainda interoperabilidade entre aplicações, redução de recursos na implementação (e, consequentemente, no preço final) e uma melhor eficácia do conhecimento das pessoas, uma vez que um corpo de conhecimento não será útil apenas para um único produto.

Identificação de serviços adicionais e garantias associados à aquisição de uma licença

Identificação de serviços adicionais (instalação, manutenção, suporte, novas versões, correcções de erros, ...) e garantias que podem estar associados à aquisição de uma licença, identificando as respectivas características e SLAs associados. No mundo do software livre, temos vários cenários habituais:

1. Empresas multinacionais com oferta Enterprise: RedHat, Novell, Canonical

   • Helpdesk (um conjunto de horas limitado ou número de incidentes pré-definido)
   • Correcções de bugs e problemas de segurança durante o tempo de vida do produto (habitualmente entre 9 e 84 meses[5])
   • Actualização de software para novas versões enquanto o contrato for válido
2. Distribuidores
   • Actualizações e correcções de segurança

3. Empresas locais que oferecem serviços chave na mão (Full Service Providers)

   • Instalação
   • Manutenção preventiva
   • Suporte ao utilizador
   • Correcção de erros
4. Suporte
   • Tempo de resposta máximo
   • Tempo de resolução máximo

5. Garantias de funcionamento (SLA Service Level Agreements)

   • Valores máximos para downtime num determinado período de tempo (fiabilidade).

   • Garantia de tempo de resposta do sistema a determinadas cargas (métrica depende do negócio).
   • Indemnização em caso de processo judicial por infracção de propriedade industrial ou direitos de autor referentes ao software (com ou sem limitação do valor)

Em quaisquer dos casos, o suporte tem um modelo de pricing diferente do software em si. Por isso recomendamos que a licença inclua apenas a garantia de tempo de vida (correcções de segurança e funcionalidade durante o tempo de vida) e que quaisquer outros serviços sigam o modelo de Projectos que integrem software proposto abaixo.

Informação Complementar Pedida

Definição de pacotes de soluções básicas que devem ser considerados pela administração

Nenhum. Qualquer agrupamento de soluções de software incluirá pacotes que serão desnecessários para uma parte dos utilizadores. Existem várias situações em que as aplicações desnecessárias foram usadas como forma de evitar a entrada de concorrentes em determinados mercados, causando custos maiores de licenciamento a prazo.

Identificação dos requisitos para fornecer licenças de software e serviços associados: autorizações, certificações, ...

Nenhuma para além das já identificadas na secção Garantia de Suporte. Quaisquer outras restrições irão limitar a oferta sem, na nossa opinião e experiência, trazer qualquer vantagem à Administração Pública.

Definição de critérios ambientais a serem utilizados

Consumo de energia provocado numa plataforma normalizada. As ferramentas com um maior desempenho, terão um menor custo ambiental (por necessitarem de menos hardware, menos energia e menos refrigeração). A implementação eficaz de normas de power management pode ser facilmente inutilizada por um programa ou um driver mal implementado. Pelo que o único critério que podemos recomendar é comparar software com base no consumo eléctrico de uma utilização típica definida no caderno de encargos.

Identificação ao nível do distrito da capacidade de suporte

A ANSOL não fornece suporte. Algumas empresas com capacidade de o fazer estão na lista de Serviços de Software Livre presente em http://ansol.org/servicos/.

Identificação dos tipos de serviços associados que devem ser ponderados: só licença, suporte, manutenção, desenvolvimento... indicando métricas e indicadores de comparação

Qualquer licença de software adquirida pela Administração Pública deve incluir actualizações de segurança pelo tempo previsto de utilização no caderno de encargos. Consideramos isto o mínimo necessário para garantir que uma compra realizada é, de facto, utilizável durante o prazo em que foi adquirido.

Nos casos em que o tempo de vida do produto cesse antes do final do prazo previsto, a aquisição deve incluir a actualização para uma versão mais recente que seja suportada até ao prazo previamente definido.

Manutenção preventiva, desenvolvimento e outros serviços devem ser considerados à parte. Ver a secção Projectos que integrem a aquisição de software.

Condições de fornecimento: SLAs, alocação, ciclo de vida, upgrades concorrenciais...

No nosso entender as condições mínimas para um fornecimento de software à Administração Pública estão definidas na secção Proposta de categorização (árvore) do software base a incluir no CPA orientada às necessidades da AP, caracterizando-a com os respectivos requisitos (próprios da AP (ie. POCAL), do mercado, internacionais, de Interoperabilidade, normas/standards do mercado (OpenDocumentFormat - ISO/IEC 26300, XML,... ), certificações, ....

Proposta de modelo de licenciamento: temporal, utilizador, medidas de negócio, clientes, ciclo de vida...

No caso de Software Livre, a licença não está limitada à partida. O mesmo não acontece com os serviços de suporte.

Identificação de medidas de avaliação do envolvimento social e ambiental entre as empresas que queiram fornecer ao estado

Não aplicável.

Apresentação do modelo de representatividade dos distribuidores e das Software Houses

A ANSOL não fornece suporte. Algumas empresas com capacidade de o fazer estão na lista de Sercviços de Software Livre presente em http://ansol.org/servicos/.

Outras questões a ter em conta

Obrigatoriedade de aquisição

A obrigatoriedade de aquisição através do PNCE inclui o risco de reduzir a oferta, reduzindo a capacidade de negociação da Administração Pública, podendo resultar num aumento dos custos do licenciamento do software. Por isso recomendamos que não deve existir obrigatoriedade de aquisição através da plataforma da ANCP de licenças de software, excepto no caso em que seja necessário um concurso público internacional.

No entanto, para garantir o não desperdício de dinheiro, quando é realizada uma consulta ou um concurso público que encaixa numa das categorias em causa, participarão automaticamente os contratos realizados pela ANCP como concorrentes.

Necessidade de memória no sistema

Nos processos actuais, é possível a um fornecedor não cumprir aquilo a que se compromete sem ser prejudicado por isso (as instituições não têm ilusões de que não ganhariam em tempo útil na justiça). Sabemos de fornecedores que, ao longo de anos, não cumprem aquilo para que são contratados, sem que isso afecte outros processos de aquisição. Tendo em conta o custo deste comportamento (a entidade que contrata acaba por gastar mais dinheiro a comprar a mesma solução), recomendamos que seja criada alguma forma de memória no sistema.

Numa primeira fase, essa memória consistiria num registo público de notificações de incumprimentos que reuniria todas as situações de uma forma documentada, de incumprimento num fornecimento à administração pública. Reuniria também as respostas públicas que o fornecedor entender dar à notificação de incumprimento.

Numa segunda fase, seriam tiradas métricas desse registo de notificações (rácio de notificações sobre número de contratos, por exemplo) que seriam utilizáveis nos processos de decisão de aquisição da administração pública.

Projectos que integrem a aquisição de software

No caso de um projecto ou serviço que inclua a necessidade de licenciamento de software, recomendamos que, na avaliação do custo do projecto sejam integrados os respectivos custos de software com base nos contratos realizados no âmbito do PNACE.

Recomendamos o mesmo a aquisição de qualquer software que exija serviços ou equipamento informático para ser posto em produção. A aquisição de um software mais barato que exige várias vezes o seu custo em equipamento informático sai caro.

Transparência

Toda a documentação referente à compra deve ser pública. Tal inclui (não exaustivamente):

• Aviso de publicação
• Caderno de encargos
• Respectivos anexos (técnicos e não-técnicos)
• Critérios de adjudicação
• Decisão final
• Contrato realizado

Para além de adicionar mais transparência ao sistema, esta medida possibilita uma melhoria da documentação (uma vez que é possível usar como base o que foi construído antes) e uma maior oferta, uma vez que os avisos nem sempre esclarecem correctamente sobre o que se está a pedir (ajudando na redução de custos).

O facto de um caderno de encargos ser público não afecta o pagamento de uma taxa de acesso ao concurso para cobrir o custo de criação do caderno de encargos.

Software de Distribuição Gratuita

Todo o software que esteja disponível de forma gratuita para a Administração Pública (assumindo que cumpre os requisitos explicitados acima) deve estar presente no catálogo.

Este software pode ser adquirido de duas formas distintas: um acordo de licenciamento que abarca toda a administração pública ou uma licença que não impõe limites de distribuição.

Critérios de Avaliação

Recomendamos que o conjunto de critérios para a aquisição de software seja o mínimo indispensável, evitando a desqualificação de concorrentes por razões diversas dos interesses da Administração Pública. Do nosso ponto de vista, cumpridos os requisitos mínimos referidos acima os critérios para avaliação devem ser (por ordem decrescente de importância):

1. Cumprimentos dos requisitos funcionais
2. Cálculo previsional de Total Cost of Ownership (TCO):
   • Custo de pessoal (utilização, administração, manutenção preventiva) (*)
   • Custo de hardware para a carga particular e para todo o período de vida do produto
   • Custo de licenciamento
   • Custo de serviços de instalação
   • Custo de suporte e manutenção
   • Custo de exportação/obtenção de dados
   • Tudo dividido pelo tempo de utilização prevista do produto
3. Normas abertas suportadas

Chamamos a atenção que não nos esquecemos do preço. Este está omisso da lista acima exactamente por considerarmos que não faz sentido. O preço é apenas um custo inicial, representando o TCO o verdadeiro compromisso financeiro realizado com a compra. Por isso consideramos que utilizar o preço como base não é a forma mais correcta de avaliar um processo de compra.

(*) mesmo se os recursos são internos e já existentes.

Acesso aos acordos-quadro

Para evitar a repetição da situação que se viveu com a anterior central de compras do estado, recomendamos que, pelo menos, uma vez por ano seja possível a actualização dos acordos-quadro. Estes concursos não têm de resultar na resolução dos contratos ou acordos-quadro existentes e têm a vantagem de permitir o acesso a empresas que por uma razão ou outra não tenha entrado no PNCE na altura certa.

Do nosso ponto de vista deviam-se enquadrar outras formas de acesso (tendo em conta os respectivos limites legais e financeiros) para além do concurso público internacional. Num país como Portugal, onde o mercado de Tecnologias de Informação é composto maioritariamente por PME, a exigência de um concurso público internacional limita, à partida, o número de fornecedores a que a Administração Pública poderá recorrer.

Software Livre

O software livre é todo o software que permite ao seu utilizador:

• A liberdade de executar o software, para qualquer fim.
• A liberdade de estudar o funcionamento de um programa e de adaptá-lo às suas necessidades.
• A liberdade de redistribuir cópias.
• A liberdade de melhorar o programa e de tornar as modificações públicas de modo que a comunidade inteira beneficie da melhoria.

O que, para organizações como a Administração Pública, significa (respectivamente):

• Liberdade de fazer o seu trabalho.
• Independência do fornecedor.
• Liberdade para crescer (ou escalar uma solução).
• Partilha de custos de suporte.

Numa nota final, sendo tidas em conta as sugestões acima dadas, não é necessário dar qualquer preferência dada ao software livre no processo de aquisição do estado. As sugestões dadas no sentido de alargar o mercado de compras da Administração Pública são suficientes para permitir a concorrência no mercado. Esse é um dos passos mais essenciais para a adopção de software livre na Administração Pública portuguesa.

Notas & Referências

1. Versão completa do PNCE - http://www.compras.gov.pt/NR/rdonlyres/E35265AF-6924-475A-A4B1-A035902337B4/2323/V_Prog_Nac_Compras_Elec.pdf

2. Valor limite do procedimento de ajuste directo.

3. Survival Guide to Microsoft Windows Vista Licensing - Practical and Simple Suggestions for Lawyers - http://shearer.org/VistaForLawyers

4. Política de Patentes da W3C - http://www.w3.org/Consortium/Patent-Policy/

5. Tempo de vida de produtos RedHat - http://www.redhat.com/security/updates/errata/

6. What Should Governments Examine in Acquiring COTS Open Source Software (OSS)? - http://www.dwheeler.com/government_oss.pdf

7. Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! - http://www.dwheeler.com/oss_fs_why.html