Módulo 2: Planejando a publicação de dados

Olá,

Neste tópico, é possível compartilhar discussões públicas e dúvidas sobre os conteúdos e temas abordados no segundo módulo do curso.

Basta responder a esta mensagem. Se tiver dúvidas que não queiram postar publicamente, podem usar também o nosso chat. As instruções estão na plataforma do curso.

1 Like

Bom dia, pessoal.

O módulo 2 me fez lembrar de questões que costumamos responder sobre os critérios para atendimento da demanda habitacional. A demanda aberta, que é atendida pela COHAB a partir de cadastro voluntário que as pessoas fazem, é selecionada por um sistema que deve realizar sorteio conforme as regras do programa em que o empreendimento foi produzido, como o Minha Casa, Minha Vida.

Fico impressionado como até agora ainda não recebemos questionamento para mostrar os algoritmos usados nesse sorteio, ou ao menos eu não vi isso acontecer, e seria um ponto que se eu estivesse “no lado de fora” certamente iria cobrar transparência dessa caixa preta.

Vamos aproveitar então para levantar essa questão internamente, antes de sermos cobrados por fora.

3 Likes

Uma questão sobre o que está apresentado agora é se devemos publicar o CPF inteiro, ou apenas anonimizado, das pessoas que receberam unidade habitacional. Já sugeriram consultar a Controladoria Geral do Município para receber essa resposta, mas aproveito para puxar a discussão sobre que tipo de problema poderia ter, ou vantagem.

2 Likes

A questão de proteger informação pessoal em processo administrativo preocupa um pouco neste momento, em que a gente percebe que a maioria das pessoas (inclusive nós aqui) ainda não sabe classificar os documentos que gera em processo eletrônico (como o SEI!), e acaba deixando públicos documentos que deveriam estar classificados como restritos, por conter informação pessoal.

1 Like

A discussão de hoje foi muito pertinente e ter visto como ainda temos tantas opiniões conflitantes sobre o assunto foi muito interessante. Entretanto, eu percebo, no meio em que convivo uma despreocupação enorme em relação à abertura de dados e à proteção de dados. Parece que estes assuntos não permeiam o pensamento das pessoas. Temos um grupo muito bom discutindo a LGPD e espero que este grupo consiga fazer a diferença.

2 Likes

Oi Marco,
Seu caso me fez lembrar um estudo sobre a concessão de créditos e como a avaliação de risco e o uso de dados pessoais pode acarretar condutas discriminatórias nestas concessões em bureaux de crédito (“BdC”).

Esse estudo de caso sobre Transparência e Governança nos algoritmos foi feito pelo ITS-Rio em 2017: https://itsrio.org/pt/publicacoes/transparencia-e-governanca-nos-algoritmos-um-estudo-de-caso/

Talvez te interesse :slight_smile:

1 Like

Oi, Marco! Esta é uma questão interessante e não há uma resposta definitiva. Como a Miriam comentou na aula ao vivo (para quem quiser assistir novamente, ela fala sobre isso especialmente a partir do minuto 26 - o vídeo já está disponível na plataforma do curso), cabe ao poder público encontrar estratégias para reduzir a formação de perfis individuais a partir do uso de CPF (publicar somente parte do número, por exemplo) ou consultas cruzadas (exemplo: encontrar facilmente informações sobre salário e moradia).

1 Like

Olá a todos, nos link’s da aula 2.7 Transparência dos Algoritmos há um link ‘quebrado’ referente a Lei por uma República Digital,2016.
Se possível, ajustem o mesmo.
Gostei muito dessa parte 2 do curso.
obrigado

1 Like

Olá,

O link anterior sobre Lei por uma República Digital, 2016 da aula 2.7 Transparência dos Algoritmos realmente não direciona para o conteúdo desejado.
A aula foi atualizada e o link foi substituído por “Jornal Oficial da União Europeia L119, 4 de maio de 2016, p. 1–88”

Boa noite!

Creio que a pergunta 7 do módulo 2 possa ter misturado os conceitos de software livre e de software público. Gostaria de provocar uma discussão se existe esta diferença ou não.

Software livre garante direitos ao usuário do software. Uma dessas liberdades é a de decidir sobre compartilhar o código com outras pessoas ou publicamente.

  1. Não compartilhar quando alguém pedir também é um direito. Exemplo:gnu.org/licenses/gpl-faq.en.html#CanIDemandACopy

  2. O software não precisa estar em repositório público para ser livre. Exemplo:gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic

Concordo ser fundamental difundirmos o quão importante software livre é para governo. Ele possibilita auditorias, melhorias e compartilhamento dentro e fora do governo. Os ganhos envolvem redução de investimentos redundantes, aumento da autonomia e da transparência.

Nesse sentido, a LAI preceitua como padrão a transparência e a publicidade sem necessidade de solicitações. Logo, faz sentido assumir que, por padrão, softwares livres usados por órgãos públicos brasileiros devem ser disponibilizados publicamente. Contudo, a LAI também prevê exceções, e é nesse ponto que entendo existir a distinção. É muito relevante que um software de inteligência para segurança pública possa ser auditado e melhorado pelo governo, mas a obrigatoriedade de sua publicação é discutível. Uma solução para identificar sonegação fiscal talvez entre no mesmo cenário. Seriam softwares livres, mas não seriam necessariamente softwares públicos.

Não prever essa distinção pode causar resistências internas à publicação como um padrão. Por isso, creio serem muito relevantes os exemplos demonstrados na aula 1.7 do curso, da “Public money, Public code”, e do Governo Federal e sua Portaria, onde fizeram essa distinção → gov.br/governodigital/pt-br/software-publico/portaria-46.pdf

Por fim, e aproveitando a menção à Portaria do Governo Federal, existe mais um ponto controverso que gostaria de colocar para discussão. O parágrafo único do artigo 5º dessa Portaria veda a criação de versão comercial de software derivado de software público brasileiro. Já tive conversas com colegas que entendem fazer sentido não permitir que softwares públicos sejam utilizados para obtenção de lucro. O TCU também já se posicionou sobre um caso: gov.br/servidor/pt-br/assuntos/noticias/2019/01/tcu-declara-inidonea-empresa-que-comercializou-programa-derivado-de-software-publico-brasileiro

Contudo, os principais movimentos de software livre e código aberto entendem que isso vai contra as liberdades básicas do software livre, e até mesmo dificulta o crescimento da comunidade de desenvolvedores ao dificultar que o movimento seja financeiramente interessante. Cabe destacar que a nova solução seria comercial sem ser proprietária. Continuaria sendo software livre passível de auditoria, modificação e compartilhamento por quem o adquirisse ou contratasse.

  1. Restrições ao uso do software livre (inclusive para fins comerciais) fortalecem o uso de software proprietário
    Fonte1:gnu.org/licenses/gpl-faq.en.html#NoMilitary
    Fonte2:gnu.org/philosophy/programs-must-not-limit-freedom-to-run.en.html
    Fonte3:fsf.org/bulletin/2017/fall/respecting-freedom-is-better-for-business

Aguardo comentários!

Excelente questão @ferluccabar! Respondi movendo esta discussão para este outro tópico. Vamos seguir a conversa por lá?

Concordo plenamente com você caro amigo, sobretudo no fator econômico. Enquanto economias prósperas e bem sucedidas de primeiro mundo utilizam aplicações Linux com distribuições Ubuntu utilizadas em sites, servidores e máquinas dos usuários em diversos órgãos e níveis de governo, o Brasil esbanja dinheiro público e mostra todo o seu poder econômico kkkk pagando com prazer licenças bilionárias às grandes empresas de software proprietários. Além disso, a abertura dos códigos é algo fundamental para poder melhorá-lo no interesse do órgão e da sociedade e baseado na “expertise” do seu desenvolvedor, a possibilidade de auditá-lo garantindo cumprimento da legislação e ganho de confiança entre administração pública e seus contribuintes são motivos adicionais.

O CPF é um documento (dado) pessoal e jamais pode ser publicado de forma integralizada, junto ainda a informações identificáveis, como o nome, o Governo Federal publica o CPF em seus sítios na internet restringindo o início e o fim de suas partes identificáveis: Ex.: *.654.256- .
Certamente que quando se trata de criança e menor de 18 anos a informação, mesmo assim restrita não deverá ser publicada, pois a criança no Brasil possui direitos de proteção bastante rígidos de acordo com o ECA. Em muitos outros países isso pode não ocorrer, por exemplo é o caso dos EUA que menor é imputável e possui os mesmos direitos e responsabilidades civis e criminais à partir dos 12 anos.
O grande problema hoje meu amigo se formos analisar essa questão é a legislação brasileira que é uma para o governo federal, outra para o estado e outra para o município graças a divisão administrativa dos entes federados. O CPF que é documento obrigatório na esfera federal não é assim na lei para os municípios, sendo apenas orientado para a constituição de comissões e órgãos para legislar sobre sua obrigatoriedade. Isto causa um problema em sistemas de informação já que o CPF é o único documento nacional que em tese pode ser utilizado como chave única. Isto causa atraso na identificação, integração de bases, ainda maior já não bastasse as restrições tecnológicas e estratégias dos órgãos que as administram. O CPF já é documento único exigido em nível federal simplificando a burocracia de documentação e facilitando os processos de auditoria e integridade das bases de dados em sistemas públicos.