Ir para o conteúdo
ou

Software livre Brasil

 Voltar a Blog Paulo S...
Tela cheia

Reflexão sobre o uso de ferramentas livres e não livres na nuvem

2 de Dezembro de 2015, 13:51 , por Paulo Santana - 55 comentários | 4 pessoas seguindo este artigo.
Visualizado 378 vezes

Há alguns dias fizemos uma reunião para iniciar os trabalhos de organização do FLISOL 2016 em Curitiba e alguns colegas que estavam participando pela primeira vez do grupo sugeriram usar o Slack como meio de comunicação entre os participantes, em substituição ao e-mail. Segundo o pessoal que sugeriu e que usa essa ferramenta em outros projetos, a vantagem de usar uma plataforma de web chat é poder agilizar as conversas e organizar melhor os trabalhos.

Na Comunidade Curitiba Livre usamos basicamente duas formas para comunicação interna: lista de discussão (e-mail) e o Telegram. Por isso poucos dias após a reunião do FLISOL, começamos a discutir se realmente era necessário usar uma nova ferramenta ou se deveríamos continuar com o que já estamos habituados. Pessoalmente acredito que sempre é válido experimentar novas soluções, desde que elas nos tragam benefícios reais como parece ser o caso de uma plataforma web chat. Mas também ficamos preocupados que se insistirmos em usar a lista de discussão, os novos voluntários possam se afastar por achar o e-mail uma forma não muito atrativa para continuar ajudando.

Decidimos manter o Slack até que possamos fazer outra reunião presencial para rediscutir o assunto, mas aí veio o segundo (e principal) problema: ele não é Software Livre, ou seja, o código não está disponível para ser baixado e usado livremente. Para quem acredita nos ideais do movimento Software Livre, usar softwares não livres sempre incomoda bastante. Não que isso nunca tenha acontecido no nosso grupo, o próprio Telegram não é Software Livre, o problema é que quanto mais exceções abrimos, mais ficamos reféns de soluções fechadas. Essa discussão sobre o uso de softwares fechados "na nuvem" já aconteceu em outras oportunidades dentro do nosso grupo e a questão central sempre foi se devemos ou não usar softwares não livres mesmo que eles tragam benefícios. Dessa vez fiquei refletindo bastante sobre o tema e decidi escrever esse texto.

Vou definir como softwares "na nuvem" os sistemas desenvolvidos e hospedados por terceiros e usados via web, ou seja, nós só usamos os serviços oferecidos por eles e não precisamos "baixar e instalar" no nosso computador pessoal. Observando todas as nossas discussões anteriores, percebi que para começar a usar um software na nuvem precisamos analisar três aspectos:

  1. A qualidade do software (serviço);
  2. Se o código é livre ou não;
  3. Como funciona a hospedagem.

A primeira questão é se o software é realmente bom e se teremos ganhos de produtividade ao utlizá-lo. No momento lembro dos softwares abaixo que, no meu ponto de vista, apresentam esses benefícios e que foram (ou ainda são) utilizadas no nosso grupo:

  • Google Docs para a criação compartilhada de documentos;
  • Facebook e Twitter para divulgação das nossas atividades principalmente para o público leigo;
  • Meetup também para a divulgação das nossas atividades mas como alternativa para quem não quer usar o Facebook;
  • Dropox para armazenar arquivos compartilhados;
  • Telegram para comunicação em grupo;
  • Slack para comunicaçao em grupo e organização dos trabalhos por ter integração com outras ferramentas.

Vou chamar esses softwares de "líderes de mercado" porque na minha opinião, eles são os que desempenham melhor as funções a que se propõe.

O problema é que todos esses líderes de mercado não tem o código aberto, o que nos leva ao ponto dois dos três aspectos citados anteriormente. Alguns desses softwares possuem alternativas livres, mas infelizmente na grande maioria dos casos esses substitutos não oferecem as mesmas vantagens ou não possuem a mesma audiência (no caso das mídias sociais) que os softwares não livres. Podemos usar:

Quero reforçar que todas essas soluções livres são ótimas alternativas para evitar as soluções fechadas, mas infelizmente por melhores que elas sejam, não conseguem (ainda) oferecer exatamente as mesmas vantagens dos líderes de mercado.

Para complicar um pouco mais temos o ponto três, que é a hospedagem. Quando usamos os líderes do mercado, não nos preocupamos onde o software está hospedado porque o serviço está alí sempre disponível quando precisamos, ele está na "nuvem". Algumas das alternativas livres não são oferecidos como serviços, ou seja, temos que baixar o software e fazer a nossa própria hospedagem. Idealmente cada pessoa ou grupo deveria manter os softwares com que trabalha em um servidor próprio afim de garantir a sua liberdade e privacidade. Mas muitas vezes não é possível ter um servidor próprio seja por custo ou por desconhecimento técnico de como fazer.

E aí nos colocamos em um dilema com duas possibildades principais:

  1. Usamos os serviços dos líderes de mercado que nos ajudarão a ter mais produtividade ou a ter mais audência, sem a preocupação com hospedagem, abrindo mão da nossa liberdade e privacidade, mesmo que estes não sejam softwares livres? ou
  2. Usamos apenas soluções que tem o código aberto, com algumas limitações e que na maioria dos casos teremos que providenciar a nossa própria hospedagem, mas nos mantendo fieis aos ideais do movimento Software Livre?

É possível notar que grupos que participam de discussões mais tecnológicas como os de linguagens de programação e CMS's, tendem a optar mais pela primeira alternativa, ou seja, eles usam serviços que vão ajudar na comunicação e produtividade indepentende se as ferramentas são ou não softwares livres. O que mais é levado em consideração é se essas soluções apresentam vantagens para o grupo. Tanto é que muitos desenvolvedores não usam GNU/Linux em seus computadores pessoais, optando por sistemas operacionais proprietários. Obviamente isso não é regra geral, sempre existem excessões nesses grupos com pessoas mais preocupadas com a questão da liberdade e privacidade.

Quando o grupo é mais voltado as discussões filosóficas/sociais/culturais do uso e desenvolvimento de Software Livre, como é o caso da Comunidade Curitiba Livre, da Associação Software Livre.Org, e de vários outros grupos, o fato da ferramenta ter o código aberto passa a ter mais importância do que as vantagens oferecidas pelas soluções não livres. Mesmo que o software usado esteja sendo hospedado por terceiros, ter acesso ao código e ter a possibilidade de baixar e instalar a sua própria instância deixa as pessoas mais confortávéis para usá-lo.

Percebo que a maioria desses grupos mais preocupados em usar softwares livres tem adotado uma terceira via que não é tão complacente com todos os softwares fechados na nuvem e não é tão "radical" para usar apenas softwares livres que é: sempre que possível, usar ferramentas de código aberto para a organizar atividades e eventos (indepentende se ele é hospedado por terceiros ou se será necessário fazer a própria hospedagem). E usar ferramentas fechadas, especialmente de mídias sociais, para divulgar as atividades para o público em geral, possibilitando assim alcançar principalmente pessoas que não são da comunidade de Software Livre.

Como mantenho no meu site uma lista dos eventos de Software Livre que acontecem pelo país, não posso terminar esse texto sem citar um fato que me chamou a atenção recentemente: a quantidade de eventos que passaram a utilizar soluções fechadas como Eventbrite e Doity, provavelmente pela facilidade que esses sistemas oferecem para organizar desde a inscrição até a programação. Além de não ser necessário desenvolver um sistema e manter em um servidor próprio. Mas o preço é novamente a falta de liberdade de ter acesso ao código e muito provavelmente a falta de privacidade já que essas empresas devem aproveitar de alguma forma os dados dos usuários cadastrados. Esses sites são um grande exemplo do antagonismo criado pela "facilidade de uso/comodidade" x "código aberto/liberdade/privacidade".

O objetivo desse texto não foi dizer "use isso" ou "não use aquilo", mas promover uma reflexão sobre esse tema tão complicado e quem sabe provocar algumas respostas. Por fim coloco abaixo dois banners de uma campanha da Free Software Foundation Europe (FSFE):

 

Thereisnocloud

 

Thereisnocloud-2


55 comentários

Enviar um comentário
  • 63namesmallworldcover minorThiago Zoroastro
    3 de Dezembro de 2015, 2:58

    FSF preocupa-se que as pessoas saibam computação

    Para ter melhor domínio sobre o computador que utilizam. Preocupam-se em fazer o usuário de computador não emburrecer-se com termos acomodantes como "nuvem" e outras facilidades que comprometem a liberdade do software e do usuário.

    Exercer a liberdade no software é muito importante na computação. As pessoas não costumam entender que é muito difícil e chato não ter liberdade de software. E como a falta disso nos torna tão superficiais.


  • 63namesmallworldcover minorThiago Zoroastro
    3 de Dezembro de 2015, 3:01

     

    Superficiais no sentido de: por mais que professores dêem a disciplina "Programação de Computadores" em Física Licenciatura e sejam doutores, normalmente ensinam Pascal e não C, usam Windows e não fazem uso da linguagem na prática. Usam 'linux' Android no celular e acham que 'linux' é difícil ou sem-valor. Ensinar Pascal ou Portugol em vez de C é atrasar o estudante em uns 40 anos úteis de programação em computadores.


  • Foto de curr culo minoradfeno
    5 de Dezembro de 2015, 13:46

    Sobre Telegram, Actor, e serviços descentralizados, e sua correta nomenclatura

    Este assunto é realmente complexo. Eu congratulo todos aqueles que se dispoem a discutir sobre este.

    Quanto ao Telegram, APENAS seu cliente é software livre[1]. Ademais, EU entendo por qual motivo secundário consideram o Telegram como não livre: assim como eu, vocês devem estar proecupados com a centralização da Internet e, diferente de mim, desejam hospedar seu PRÓPRIO servidor de Telegram. Mas é necessário entender que ele é ATUALMENTE software livre[1], e não se pode dizer ao contrário A NÃO SER QUE se encontre alguma dependência em software não livre, tanto em tempo de COMPILAÇÃO, quanto em tempo de EXECUÇÃO (exceto nos casos em que o próprio projeto é um esforço de engenharia reversa de tal dependência não livre, ou caso objetive substituir a dependência não livre, ou parte dela onde, neste e em vários outros casos CONFORME A REFERÊNCIA [2], é aceitável usar, recomendar ou redistribuir o software não livre JUNTO COM o software livre que objetiva substituir ele ou parte dele, APENAS para fins de TESTE/FEEDBACK e DESENVOLVIMENTO do software LIVRE, como foi o caso do projeto GNU em seus primeiros estágios de desenvolvimento[2]), ou caso a documentação OFICIAL recomende ou ensine um software não livre (observadas todas as exceções anteriores, e EXCLUINDO tópicos públicos de fórums e chats, mas INCLUINDO wikis, e TALVEZ incluindo tópicos especiais/fixos de fórums), caso se encontre código ofuscado, ou algum código escrito em JavaScript minificado (com variáveis de nomes impossíveis de serem facilmente descritas e com uma estrutura muito minimalista, geralmente sinalizado por uma série de comandos que poderia ser perfeitamente separados por quebras de linha mas que, ao invés disso, foram separados por caracteres terminiativos, como o ";"/ponto e vírgula na linguagem dos scripts escritos para GNU Bash e para os demais shells que aceita este caractere como terminativo), excetuando os scripts ofuscados ou minificadso escritos em JavaScript que possuam toda a notação computacional necessária para serem corretamente reconhecidos como software livre pelo GNU LibreJS[3][4][5].

    Nota (parágrafo único): Todos nós sabemos, inclusive EU, que o movimento filosófico do software livre muda constantemente, similar, logicamente, aos programas de computador e suas diferentes versões. Assim, o que era livre antes, pode se tornar não livre depois, E VICE-VERSA. Então, ENTENDEREI o motivo da afirmativa de que "o Telegram é software não livre" caso você tenha se referido a uma pesquisa que fizesste no Free Software Directory a MUITO tempo atrás. Por via das dúvidas, sempre que você alegar que algum software é livre ou não, aponte para alguma prova, principalmente se ela vier do Free Software Directory ou dos repositórios das versões ATUALMENTE ESTÁVEIS das distribuições livres. Lembre-se que o Free Software Directory é construido por COLABORADORES e poucos deles têm completo conhecimento da filosofia do software livre (eu tenho conhecimento incompleto, mas não tenho tempo para me dedicar somente ao diretório). Então, PODE SER que o Telegram seja desconsiderado como software livre futuramente, fique de olho na entrada sobre o mesmo no Free Software Directory[1]. (Fim da nota).

    Além disso, se vocês estão preocupados com o fato do programa-servidor do Telegram não ser software livre (SE, E APENAS SE, é que este programa-servidor PODE AO MENOS ser baixado, pois desconheço a resposta), impedindo vocês de hospedarem seu próprio servidor de Telegram por se preocuparem com as liberdades tiradas de vocês pelo desenvolvedor do software ao HOSPEDAREM o servidor, eu concordarei plenamente em dizer que O SERVIDOR do Telegram não é software livre.

    Contudo, SE o programa-servidor do Telegram NÃO ESTÁ disponível ao público, nem mesmo para compra, mesmo que somente em forma executável, então a SITUAÇÃO MUDA, e MUITO. Neste caso, quem estaria usando software não livre seriam os próprios hospedeiros OFICIAIS do servidor do Telegram. Isso é similar ao caso do Twitter, Facebook e etc., principalmente pelo fato de que, APESAR de não se poder julgar serviços na Internet como livres ou não livres, eles podem trazer outros problemas[6] (quebra de privacidade[6], uso de software não livre escrito em JavaScript que é interpretado/usado/executado no computador do cliente[6] e, por último, MAS NÃO MENOS importante, podem acarretar em problemas de centralização das comunicações da sociedade[6]).

    Quando se considera o CLIENTE do Telegram como software não livre, tanto pela indisponibilidade do código fonte e licenciamento incorreto do código fonte no caso do PROGRAMA-SERVIDOR, quanto pela completa indisponibilidade do PROGRAMA-SERVIDOR, corre-se o risco de chegar a conclusões extremas como: "Jitsi não é software livre pois consegue comunicar-se com o protocolo de mensagens instantâneas do Facebook e assim, não devo recomendá-lo, ou deve-se remover tal função específica"[7], o que pode tornar ainda mais difícil os esforços em prol de uma sociedade digital livre, VISTO QUE as pessoas têm níveis DIFERENTES de dependência em software não livre, ou em serviços centralizados. Este caso seria similar ao do Debian que, pelo menos na versão de codinome Squeeze, NEGAVA a existência de um software LIVRE que pelo menos DECODIFICAVA/REPRODUZIA arquivos no formato MP3 (e seus possíveis codecs/codificadores de áudio), mas recentemente eu soube de um esforço conjunto entre a Free Software Foundation e o projeto Debian em terminar os desacordos entre os dois[8], tanto é que o GNU+Linux Debian é considerado como livre pela Free Software Foundation[8], mesmo que não oficialmente por esta[9], bastando para isto que o apoiador ou ativista recomende ou faça a remoção das entradas referêntes aos repositórios "contrib" E "nonfree"/"non-free" (não me recordo como se escreve) na cópiao do sistema operacional atualmente em uso, justamente pelo fato da documentação oficial do projeto recomendar estes repositórios. Alguns usuários no fórum do projeto Trisquel ainda contribuiram com uma distinção muito interessante, que se levada a sério, pode significar uma possível aprovação do GNU+Linux Debian como sistema operacional livre[10] (PORÉM, eu não sei se o projeto Debian já está sabendo desta sugestão).

    Como eu já enfatizei diversas vezes neste texto, eu concordo que o cenário de descentralização das comunicações da sociedade na Internet NÃO É ideal (e Richard Stallman também PARECE concordar com isso ao escrever Network Services Aren't Free or Nonfree; They Raise Other Issues[6]). Por este motivo, EU não uso o Telegram, mas isso não quer dizer que não devo recomendar o Jitsi (no exemplo anterior) para quem deseja se comunicar instantâneamente no Facebook, SEGUIDO DE UMA OUTRA RECOMENDAÇÃO explicando o problema ESTRUTURAL do Facebook.

    Aliás, ao menos hoje (2015-12-05), NÃO encontrei registro aprovando o Actor como software livre nem no Free Software Directory[11], nem no repositório do F-Droid[12].

    IMPORTANTE: Este comentário também foi publicado como resposta ao mesmo tópico na lista de discussão/e-mails do Projeto Software Livre Brasil[13].

    REFERÊNCIAS

    [1] dire​ctor​y.fs​f.or​g/wi​ki/T​eleg​ram

    [2] www.​gnu.​org/​phil​osop​hy/i​s-ev​er-g​ood-​use-​nonf​ree-​prog​ram.​en.h​tml

    [3] www.​gnu.​org/​phil​osop​hy/j​avas​crip​t-tr​ap.h​tml

    [4] www.​gnu.​org/​lice​nses​/jav​ascr​ipt-​labe​ls.e​n.ht​ml

    [5] www.​gnu.​org/​soft​ware​/lib​rejs​/fre​e-yo​ur-j​avas​crip​t.ht​ml

    [6] www.​gnu.​org/​phil​osop​hy/n​etwo​rk-s​ervi​ces-​aren​t-fr​ee-o​r-no​nfre​e.en​.htm​l

    [7] dire​ctor​y.fs​f.or​g/wi​ki/J​itsi

    [8] tris​quel​.inf​o/en​/for​um/d​ebia​n-an​d-fs​f-en​ding​-dis​agre​emen​ts-s​olvi​ng-p​robl​ems-​sour​ce

    [9] www.​gnu.​org/​dist​ros/​comm​on-d​istr​os.h​tml.​en#D​ebia​n

    [10] tris​quel​.inf​o/en​/for​um/f​oxyp​roxy​-lib​re#c​omme​nt-8​3115

    [11] dire​ctor​y.fs​f.or​g/wi​ki?s​earc​h=Ac​tor&​go=G​o&ti​tle=​Spec​ial%​3ASe​arch

    [12] f-dr​oid.​org/​repo​sito​ry/b​rows​e/?f​dfil​ter=​Acto​r&fd​page​=1&p​age_​id=0

    [13] list​as.s​oftw​arel​ivre​.org​/pip​erma​il/p​sl-b​rasi​l/20​15-D​ecem​ber/​0047​57.h​tml


  • Filipe research gate minorFilipe Saraiva
    6 de Dezembro de 2015, 20:48

     

    Bom texto Paulo, valeu por compartilhar as reflexões.

    Acho que quando falamos em software especificamente voltado para comunicação, o que o movimento software livre deveria priorizar eram softwares federados, que permitam que o usuário tenha uma conta em um servidor e possa se comunicar com usuários cadastrados em outros servidores.

    Não que software de comunicação não-federado seja ruim, eles servem como boas aplicações para redes temáticas. Se adequariam a essa categoria o Actor, Rocket.chat, IRC e o Noosfero, por exemplo, assim como sites de fóruns e similares.

    Já comunicadores federados teriam uma utilização mais aberta, onde o foco sai da rede temática e vai para o usuário e suas prioridades. O e-mail serve como uma espécie de padrão balizador para essas ferramentas, e atualmente podemos colocar nessa categoria o Status.Net, Diaspora, Red# (agora Hubzilla), Jabber/XMPP, e outros.

    Sobre essas ferramentas dessa última categoria, acho que o mundo do software livre está tecnicamente bem servido, com boas opções e de muita qualidade. O problema, ao meu ver, é tanto a adoção fora do nicho de usuários de software livre e a própria grande variedade de alternativas, que não interoperam. Esse último é muito ruim porque temos um punhado de usuários em um punhado de serviços, mas que nunca está em um tamanho suficiente para ganhar "momentum" e ir aumentando a base de usuários com o decorrer do tempo...

    Enfim, essas são algumas reflexões que tenho. :)


  • Newbuddy minorMachado
    12 de Fevereiro de 2016, 16:08

    ...meses depois

    Olá!

    teve um ano no FISL que fizemos toda a organização com Wiki e dotproject(integrado a lista de emails) e RT.

    Na prática, quem usava só email conseguia seguir com suas contrbuições e fazer boa parte do trabalho de comunicar, todas as mensagens podiam ser vistas ou na aba de comentários da tarefa no dotproject ou na pagina do mailman (ou no inbox do usuário de email) e tudo estava sempre visivel a todos... e organizado em grupos de trabalho, tarefas, deadlines, marcos, etc... foi o melhor ano que tivemos, EMHO, no quisito ferramentas de apoio a organização e comunicação.


Enviar um comentário

Os campos são obrigatórios.

Se você é um usuário registrado, pode se identificar e ser reconhecido automaticamente.