[okfn-br] Licenças para dados sigilosos

Sábado Janeiro 16 16:12:54 UTC 2016

A comunidade de interessados/entendidos em aprofundar esse tipo de tema é
pequena, o ideal é discutir em inglês... Uma alternativa seria usarmos essa
outra lista
<https://discuss.okfn.org/t/reasons-to-use-a-cc-by-sa-licence-instead-of-cc-by/1765>
(aqui
na Lista OKBR sempre podermos dar um toque das novidades com os devidos
links).

Bom, a Internet está repleta de material razoável em inglês, mas vi pouca
coisa séria em português (e com as nuances do Brasil) na linha que
considero interessante...
*Vou escrever longamente, como se fosse num Blog*, e pensando nessa lacuna.

Sábado é um dia bom para escrever ;-)

- - - -

Se seguir o link acima vai reparar que, na minha opinião, as *licenças* existem
por dois motivos fundamentais,

1) como resposta a Berna <https://en.wikipedia.org/wiki/Berne_Convention>:
nunca podemos esquecer que existe uma "licença *default*" (ver licenças
implícitas <https://en.wikipedia.org/wiki/Implied_license>) universal que
estabelece automaticamente todas as restrições e direitos de propriedade...
"Direitos", que só  podem ser exercitados no sistema jurídico brasileiro e
no mercado globalizado, por poucos...  Autores e artistas seriam
beneficiados por essa mágica da "*proteção automática*", mas o Jorge aqui
da OKBR mostra como abusos foram sendo acrescentados à Convenção de Berna
<http://www.forum-global.de/jm/art06-07/desconstruindo_propriedade_intelectual.html>...
Nas últimas décadas o ativismo e a defesa por um modelo livre de
conhecimento estimularam o uso de licenças que removem todas (como na
licença CC0 <https://creativecommons.org/publicdomain/zero/1.0/>) ou a
maior parte (licenças CC-BY, Apache, MIT, CC-BY-ND, etc.) dessas
 "proteções automáticas".

2) como resposta à monopolização do mercado e tendência à apropriação
indevida do patrimônio de domínio público: licenças como a GPL e a CC-BY-SA
<https://creativecommons.org/licenses/by-sa/4.0>, com a cláusula apelidada
de *Share-Alike* (alguns preferem chamar de "strong copyleft",
pejorativamente "cláusula contaminante"). Elas garantem o acréscimo e
melhora contínuos desse patrimônio.
  PS: infelizmente não dá para criar um "universo paralelo", o software
aberto faz parte do mercado, e nesse sentido o *share-alike* precisa ser
colocado na balança <http://www.public-software-group.org/licenses> por
quem o utiliza.

Nesse contexto fica evidente o seguinte: a *licença a rigor é um contrato*,
e o que chamamos de *licença* acima são na verdade *modelos de contrato* ou
"licenças públicas <https://en.wikipedia.org/wiki/Public_copyright_license>
".
Também fica evidente o seguinte: putz (!), se é um treco assim onipresente,
cadê a "licença de Berna"? Trata-se de uma *licença implícita
<https://en.wikipedia.org/wiki/Implied_license>* mas que todos nós teríamos
obrigação de conhecer, tanto quanto a Constituição...
Mas, ler a Convenção assinada pelo Brasil é um saco
<http://www.lexml.gov.br/urn/urn:lex:br:federal:decreto:1975-05-06;75699> e
interpretá-la sem ser um jurista é quase impossível... Bom, que tal delegar
essa interpretação a muitos olhos
<https://en.wikipedia.org/wiki/Linus%27s_Law> e resumir de forma legível?  está
aqui (!), e você leitor pode ajudar a melhorar
<https://github.com/ppKrauss/licenses/blob/master/reports/implied-berne-v1971.md>
.
PS: existem outras *licenças implícitas*, muito comuns no Brasil, a mais
importante é a licença de uso dos documentos legislativos
<https://github.com/ppKrauss/licenses/blob/master/reports/implied-lex-BR-v1.md>
.

- - - -
Ainda "me sentindo num Blog", mas voltando ao tema central colocado...

Quando no Brasil falamos em *Termo de Sigilo e Confidencialidade*, ou
similar, é um contrato entre as partes (ex. a Coca-cola e o funcionário que
tem acesso ao seu segredo), e pode eventualmente fazer uso de um *modelo de
contrato padronizado*...
E só: não teria mais nada haver com uma *licença*.
O objeto de contrato nesse caso é a chamada *informação classificada*
<https://en.wikipedia.org/wiki/Classified_information>
e portanto deixa de ser uma obra autoral usual, deixa de ser "entidade do
mercado", e passa a ser de outro universo, é um objeto interno da
organização (a qual mantém a guarda ou tutela da informação)...

Exemplo. Nas escolas a programação, as apostilas, todos os documentos podem
ser "abertos" à comunidade de pais e alunos, num sistema informatizado
ideal... Mas não a "ficha do perfil aluno", com seu perfil psicológico,
histórico de problemas, etc.   Não é um documento com uma licença
diferenciada (apesar de alguns DRMs
<https://en.wikipedia.org/wiki/Digital_rights_management> tratarem assim),
é um objeto tratado em outro sistema. É até preferível que exista apenas em
papel, no arquivo a sete chaves dos psicopedagogos e coordenadores.

- - - -
Se as partes não estão preocupadas em transformar a obra em "informação
classificada", talvez aí possamos empacotar o tema numa discussão sobre
"Termos de uso do serviço", que é também um tipo de contrato, mais amplo
que as *licenças* padronizadas, referentes apenas ao uso da obra.

A questão do sigilo é central inclusive a *termos de uso* de serviços de
depósito de dados, serviços de *crowdsourcing* e serviços de apoio à
produção de conteúdo: idealmente serviços como Facebook e o Gmail deveriam
dizer nos *termos de uso* que não vão divulgar nem fazer uso comercial dos
nossos dados pessoais tidos como sigilosos. A troca de e-mails e o chat
pessoal não são públicos, e deveriam ser sigilosos no sentido também de
serem isentos do usufruto comercial (exploração em *business intelligence*
e mercado de *content leak*
<https://anistia.org.br/breve-historia-hacking-organizacoes-de-direitos-humanos-por-parte-dos-governos/>
).

No Brasil os e-mails (encriptados) contendo exames laboratoriais de AIDS ou
DNA (paternidade) foram pioneiros em cláusulas contratuais explícitas sobre
privacidade e sigilo. É um exemplo extremo: deveria ser tratado como
"informação classificada", mas serviços online dos laboratórios acharam
mais prático se defender apenas com "termos de uso". Vem funcionando sem
problemas e sem maiores modificações nos termos, há mais de 10 anos.

- - - -

Por fim, sobre contratos em geral... podemos nos espelhar no sucesso das
licenças públicas padronizadas.

O conceito de *modelo de contrato* (sério e padronizado) ainda é pouco
explorado no Brasil, na prática temos uma cópia/cola cultural de contratos
razoáveis, mas é um caos (!), que prejudica a todos...
As partes eventualmente (quando sérias) se põe a ler o contrato: em tal
caso (comum quando envolve muito dinheiro) gasta-se muito tempo lendo e,
pior, como não se baseiam em padrões,  demandam custo de horas-advogado ou
horas-julgamento para sejam de fato considerados não-nulos e
consistentes...

O que vejo no mercado brasileiro com relação aos "Termos de Sigilo e
Confidencialidade", tanto nos meus papos de bar como na experiência
profissional,
é que as empresas simplesmente usam como ferramenta do tipo "melhor que
nada", e jamais confiam no seu valor jurídico, portanto contabilizam a
relação do objeto do Termo como *alto risco*.

... Poderíamos nos espelhar nas licenças padronizadas tais como as licenças
Creative Commons (CC), e *tratar os modelos de contrato como dados abertos*
(!) de alto valor estratégico para as empresas, ONGs e governo.
*Bons modelos de contrato reduzem riscos e custos de transação
<https://en.wikipedia.org/wiki/Transaction_cost>.*

*Que tal construirmos uma Wiki de modelos de contrato?*

Em 16 de janeiro de 2016 10:54, Thiago Avila <tjtavila em gmail.com> escreveu:

> Bom dia pessoal,
>
> Alguém pode contribuir com esta pergunta da minha colega de pesquisa
> Danila Feitosa?
>
> ---------- Mensagem encaminhada ----------
> De: "Danila Feitosa" <danila.fco em gmail.com>
> Data: 15/01/2016 12:01
> Assunto: Re: Dúvidas
>
> > Bom dia Pessoal,
> >
> > Vocês conhecem alguma licença para dados privados, ou sigilosos?
> >
> > Até o momento encontrei informações que, falam que para dados deste tipo
> é aplicado um acordo de confidencialidade.
> >
> > Abraço!
> >
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20160116/19597a68/attachment-0005.html>