On Feb 24, 2007, Olival Gomes Barboza Júnior <[EMAIL PROTECTED]> wrote:
> Em 24/02/2007, às 23:04, Alexandre Oliva escreveu:
>> Sim, quando vc respondeu em PVT, eu segui em PVT. Quer que publique
>> as duas mensagens?
> Pode ser. Eu só dei reply aqui e, por algum motivo, o reply-to estava
> só pra vc.
Quando você dá reply a um e-mail, o comportamento correto é mandar a
resposta apenas para o remetente. Diversas listas tentam confundir as
pessoas definindo Reply-To: pra lista, o que quebra quando você recebe
a mensagem diretamente, sem dar chance para o gerador de confusão
fazer seu trabalho. Esta é só mais uma das razões para não que listas
não definam Reply-To. http://www.unicom.com/pw/reply-to-harmful.html
Enfim... Aqui vai o tráfego que foi em privado. Veja como é fácil de
tornar público o que foi acidentalmente privado por causa da ausência
de Reply-To: na mensagem que vc recebeu de mim. Agora imagine como
seria difícil tornar privado algo que pudesse ter se tornado
acidentalmente público por causa da presença de Reply-To:...
--- Begin Message ---
Topics:
Re: [PSL-Brasil] Escreva para a Receita Federal brasileira contra os
"Softwares Impostos"!
Re: [PSL-Brasil] Escreva para a Receita Federal brasileira contra os
"Softwares Impostos"!
--- End Message ---
--- Begin Message ---
Em 24/02/2007, às 10:43, Alexandre Oliva escreveu:
> On Feb 22, 2007, "Pedro A.D.Rezende" <[EMAIL PROTECTED]> wrote:
>
>> Olival Gomes Barboza Júnior escreveu:
>>> O q exatamente é implementado q não está coberto pelo novo
>>> licenciamento da Sun?
>
>> Segundo o co-autor, são algumas classes no classpath.
>
> Parece-me que a resposta não corresponde à pergunta ;-)
>
>
> De todo modo, discutir sobre qual JRE funciona ou não é varrer pra
> baixo do tapete a questão mais importante e mais fácil de resolver:
> por que a SRF não liberaria o código que o SERPRO desenvolveu pra ela,
> sobre o qual ela detém os direitos autorais?
Pois é, foi aqui q fiquei confuso. Eu havia entendido q o programa da
SRF é q usa classes proprietárias, assim o problema estaria nas mãos
da Receita. Pelo q vc está dizendo, o buraco é mais embaixo e a
questão está no JRE.
Acredito q a desculpa "oficial" da SRF para não permitir programas de
terceiros para fazer a declaração seria a garantia de q os cálculos
do imposto estão corretos na origem, sendo o trabalho posterior de
auditoria voltado para pegar os desvios "pra valer". Claro q isso é
apenas conjectura minha, mas, como eles não dão tanta bola pra SL por
lá, provavelmente nunca vão se dar ao trabalho de explicar suas razões.
BTW, quem desenvolveu as primeiras versões do programa foi uma equipe
da própria Receita (por acaso, colegas meus do concurso da SRF no
início da década de 90, qdo trabalhei por lá). Acredito q havia
pessoas do Serpro na equipe, mas o grosso da equipe de
desenvolvimento era da SRF. Esse pessoal já falava de uma versão Java
do produto há anos, ainda no auge do governo FHC. Inclusive, uma das
pessoas envolvidas (de BH) chegou a ir ao JavaOne receber um prêmio
pelo programa do IRPF.
[ ]s,
olival.junior
--- End Message ---
--- Begin Message ---
On Feb 24, 2007, Olival Gomes Barboza Júnior <[EMAIL PROTECTED]> wrote:
> Pois é, foi aqui q fiquei confuso. Eu havia entendido q o programa da
> SRF é q usa classes proprietárias,
Usa classes que não fazem parte da especificação. Se vc usa a
implementação da Sun, de fato são proprietárias (por enquanto). Se vc
usa outra, livre, que tenha feito engenharia reversa e as
implementado, ainda que em violação das regras de nomenclatura de
classes da linguagem Java, pode ser que funcione. Se é que existe
alguma livre que tenha feito isso.
> assim o problema estaria nas mãos da Receita.
Sim. Porque ela quer. Porque se ela liberasse o código, a gente
podia consertar essa dependência.
> Pelo q vc está dizendo, o buraco é mais embaixo e a questão está no
> JRE.
Sim e não. JRE específico e proprietário é uma dependência
indesejável, mas que poderia ser contornada se o próprio programa
fosse livre.
> Acredito q a desculpa "oficial" da SRF para não permitir programas de
> terceiros para fazer a declaração seria a garantia de q os cálculos
> do imposto estão corretos na origem,
Pois é, é desculpa furada. Abordamos isso no artigo:
Poder-se-ia argumentar que há necessidade de controle do código
fonte das aplicações e segredo sobre os formatos de arquivo e os
protocolos para impedir a submissão de declarações inválidas.
Porém, se a segurança fosse utilizada como argumento para não
exposição dessa informação, isso indicaria a vulnerabilidade do
sistema de recepção de declarações na Receita Federal: se for
possível, de maneira acidental ou intencional, induzir esse sistema
a se comportar fora das especificações, aceitando como legítimas
declarações inválidas, ele já é vulnerável e deve ser corrigido.
Não se pode depender da falta de informação de terceiros para
garantir a segurança de um sistema. As salvaguardas devem ser
internas, caso contrário algum esforço de engenharia reversa seria
muito recompensador, e provavelmente já teria sido explorado.
> como eles não dão tanta bola pra SL por lá, provavelmente nunca vão
> se dar ao trabalho de explicar suas razões.
Até que tomemos ações concretas a respeito disso. Se eles continuarem
"não se dando ao trabalho", é isso que vai acontecer.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--- End Message ---
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
_______________________________________________
PSL-Brasil mailing list
[email protected]
http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
Regras da lista:
http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil
