Marquioni
 
 
 
 
Você no Marquioni.com.br
Em breve, você poderá ser um articulista em nosso site. Cadastre-se!
 
Técnico vs. usuário: uma análise do processo comunicacional na Engenharia de Requisitos de Software
Clique aqui para mais informações de como adquirir o livro.
 
 
   
     
 
 
     
 

Selecionar idioma:

Uma breve análise da produção de software livre
 
 
Autor Carlos Eduardo Marquioni, M.Sc., PMP
 

Resumo:

Este trabalho apresenta conceitos relacionados à produção de software livre e propõe a análise da produção deste tipo de produto segundo duas linhas básicas: como fenômeno de organização da sociedade (comportamento emergente) e segundo aspectos políticos (autor como produtor). Ao longo do texto são apontadas alternativas de aprofundamento para estudo pela comunidade científica – tanto de software quanto comunicação – considerando inclusive conceitos da Engenharia de Software.

 

Palavras-chave: software livre; software de fonte aberta, autor como produtor; Cultura tratada como Engenharia; emergência.
 

1. INTRODUÇÃO[3]

 
 
Os estudos acerca da produção de software livre ultrapassaram as fronteiras da área técnica de software propriamente dita, e este tipo de produto tem sido estudado inclusive por pesquisadores da comunicação, que apontam sua criação como
 
[...] um dos fenômenos mais interessantes da cibercultura [...] [, destacando o fato que o] Brasil é reconhecido como um dos países que mais tem realizado esforços governamentais para a adoção dos ‘softwares livres’, tanto na sua administração direta, como em projetos de inclusão digital (LEMOS, 2006, p. 61).
 
Indubitavelmente, o uso crescente deste tipo de produto motiva reflexões no tema, e deixa clara a necessidade de mesclar aspectos do processo técnico de criação de software com o estudo do fenômeno comunicacional. Neste sentido, este trabalho sugere duas frentes de estudos concomitantes, complementares e que podem abordar tanto aspectos técnicos de software quanto de comunicação: uma trataria o fenômeno emergencial de produção; outra, avaliaria o contexto político de uso do produto.
Não há consenso em relação aos termos envolvidos com software livre. Neste trabalho optou-se pelo uso da categorização proposta pelo projeto GNU[4] e pela OSI[5]; vale salientar que para a FSF[6], patrocinadora original e responsável por promover o desenvolvimento do projeto GNU, “‘software livre’ é uma questão de liberdade, não de preço [...] [e] para entender o conceito, você deve pensar em ‘livre’ como ‘liberdade de expressão’, não como ‘cerveja grátis’[7]” (GNU, 2007). Assim, software livre não é sinônimo de software gratuito e pode ser comercializado[8]. Segundo a Free Software Foundation, a liberdade se dá através da possibilidade de
 
[...] qualquer pessoa utilizá-lo, copiá-lo e distribuí-lo, tanto no formato original quanto com modificações, gratuitamente ou mediante cobrança. Em particular, executar, copiar, estudar, modificar e melhorar o software. Mais precisamente, ela se refere a quatro tipos de liberdade aos usuários do software: A liberdade para executar o programa para qualquer finalidade (liberdade 0). A liberdade para estudar a lógica do programa e adaptá-lo a suas necessidades (liberdade 1). A liberdade para redistribuir cópias para auxiliar seus pares (liberdade 2). A liberdade para melhorar o programa, e disponibilizar suas melhorias ao público, de modo a beneficiar toda a comunidade (liberdade 3) (FSF-FS_DEFINITION, 2007).
 
Conforme conceituação a seguir, o acesso ao código fonte é pré-requisito para as liberdades 1 e 3.
 

1.1 CONCEITOS CHAVE

 
Para que um software seja considerado livre, ele deve possibilitar
 
[...] a qualquer pessoa utilizá-lo, copiá-lo e distribuí-lo, tanto no formato original quanto com modificações, gratuitamente ou mediante cobrança. Em particular, [dizer que se trata de software livre] significa que o código fonte é disponibilizado. ‘Sem o fonte, não há software’[9] (GNU-CATEGORIES, 2007).
 
A definição esclarece o que a FSF quer dizer com liberdade de expressão, e estabelece clara distinção em relação aos softwares proprietários[10]: software livre envolve necessariamente acesso ao código fonte. O conceito é compactuado pela Open Source Initiative, segundo a qual no software livre o “programa obrigatoriamente deve incluir o código fonte, e devem ser distribuídos tanto o código fonte quanto seu formato compilado[11]” (OPEN-SOURCE, 2007).
Apesar da definição de software livre envolver o fornecimento do código fonte, a FSF não considera sinônimos os termos software livre e software de fonte aberta (open source software). Ao invés disso, a fundação os enquadra em categorias diferentes e recomenda o uso do termo software livre ao invés de fonte aberta, devido ao fato que este segundo nome não referencia liberdade, enquanto o primeiro sim. A separação em duas categorias se deve inicialmente a aspectos técnicos.
 
Não se trata exatamente da mesma classe de software: eles [softwares de fonte aberta] aceitam algumas licenças que nós [FSF] consideramos muito restritivas, e há licenças de software livre que não são aceitas [por softwares open source]. Contudo, as diferenças entre as categorias são pequenas[12] (GNU-CATEGORIES, 2007).
 
É possível realizar uma extrapolação e considerar que o termo liberdade de expressão ultrapassa os limites dos conceitos de software livre, e entender que a informação em geral deve ser acessível por todos. Assim, é possível inserir softwares colaborativos (wiki, por exemplo) neste contexto.
Há ainda outras categorias[13] de software que podem ser citadas: freeware[14], shareware[15], software copylefted[16], software não copylefted[17], software de domínio público[18] mas para efeito deste trabalho as apresentadas são suficientes.
 
Um último conceito chave fundamental é o termo usuário que, no contexto deste artigo, deve ser entendido em um sentido amplo englobando tanto usuários individuais quanto empresas usuárias. Em termos gerais[19], usuários individuais são pessoas físicas que fazem uso de software livre e empresas usuárias são instituições públicas ou privadas. Evidentemente há usuários individuais avançados, que inclusive colaboram com a produção de software livre – engenheiros de software e programadores são exemplos de usuários individuais. Contudo, ao considerar um ambiente de utilização amplo, há usuários que não possuem conhecimento técnico profundo acerca de desenvolvimento de software, ou apresentam dificuldades na utilização do software (mesmo produtos simples como editores de texto ou planilhas de cálculo). Como exemplos de empresas usuárias podem ser citados bancos, montadoras, universidades, companhias aéreas, órgãos governamentais, entre outras. Entre as empresas usuárias em que a utilização de software livre se justifica por benefício claro estão as da iniciativa pública, devido à redução de gastos financeiros com licenças de uso de software.
 

1.2 REFLEXÕES INICIAIS

 
A afirmação de que qualquer pessoa pode alterar um software livre é passível de debate sob vários aspectos. Destacam-se dois básicos:
  •  Para realizar uma atualização em um produto de software, a pessoa necessita falar a linguagem na qual o programa fonte foi escrito. Não basta o acesso ao código fonte: é preciso conhecimento técnico (normalmente profundo) na linguagem de programação utilizada. Assim, um usuário que não tenha conhecimento em computação, ou mesmo um usuário com conhecimento em informática (com formação técnica ou não) que não programe na linguagem utilizada em um determinado software livre estaria automaticamente excluído do grupo de pessoas que pode atualizá-lo;
  • · Sob a ótica da Engenharia de Software, o software não se reduz ao conjunto de programas[20] (fontes ou compilados) que possui, mas envolve também sua planta baixa (diagramas técnicos de análise e design[21]). Como no caso da construção civil, a omissão da planta baixa pode comprometer a qualidade do produto final.
A partir destes dois aspectos básicos, é possível propor algumas reflexões analíticas. Inicialmente, é possível avaliar o grau de liberdade (quantitativa e qualitativamente falando) possibilitado por software livre, considerando tanto a disponibilidade de equipamentos (acesso ao hardware) quanto o conhecimento necessário em programação.
Em um segundo estágio, podem ser avaliadas as competências dos envolvidos no processo em relação a conceitos de Engenharia de Software; a pertinência desta análise é justificada pois, da mesma forma que distribuir computadores não implica inclusão digital, oferecer programas fonte de produtos copyleft não implica desenvolvimento de software livre.
Se o objetivo for desenvolver software para uso em escala, a análise ganha uma amplitude maior, pois é fundamental avaliar formas de oferecer e garantir capacitação aos envolvidos na produção: o aumento dos envolvidos não torna o produto menos técnico, mas pode torná-lo menos seguro (ou sugerir insegurança, pouca qualidade) aos usuários[22].
Certamente o tema permite muitas possibilidades, e este trabalho não pretende formular problemas analíticos (criteriosos ou não) acerca de todas. Contudo, parece fundamental associar as áreas de conhecimento da Engenharia de Software e comunicação – que certamente possuem uma grande intersecção – para tratar do tema. Para procurar sistematizar este estudo, o artigo reitera software livre como uma das práticas da “Ciber-Cultura-Remix” (LEMOS, 2006, p. 52) e é proposta a seguir uma decomposição do assunto em duas linhas principais: enquanto fenômeno de organização da sociedade (a partir do conceito de Emergência proposto por Steven Johnson) e em função de seu caráter político (segundo conceito de Autor como Produtor apresentado por Walter Benjamin com a atualização, Autor como Produtor Digital, elaborada por Geoff Cox e Joasia Krysa).
 

2. SOFTWARE LIVRE: UM CASO DE EMERGÊNCIA

 
“[...] conecte o maior número de mentes ao sistema [...] e logo o sistema chegará a uma fase de transição: pedaços isolados e obsessões particulares se aglutinarão em um novo modo de ver o mundo, compartilhado por milhares de indivíduos” (JOHNSON, 2003, p. 47).
 
Em termos de organização social, a produção de software livre pode ser compreendida como resultado da execução de processos de um sistema emergente. Sistemas emergentes são adaptativos
 
[...] bottom-up, e não top-down. Pegam seus conhecimentos a partir de baixo. [...] Neles, os agentes que residem em uma escala começam a produzir comportamento que reside em uma escala acima deles: formigas criam colônias; cidadãos criam comunidades [e,] (JOHNSON, 2003, p. 14)
 
no contexto deste trabalho, indivíduos com conhecimento técnico criam software livre. “O movimento de regras de nível baixo para a sofisticação do nível mais alto é o que chamamos de emergência” (ibid.).
Estudos relacionados a sistemas emergentes vêm sendo realizados pela pesquisadora de colônias de formigas cortadeiras Deborah Gordon, da Universidade de Stanford. Evidentemente, apesar de ser possível estabelecer uma analogia, é importante destacar que, no caso do sistema emergente de produção de software livre, as “partes componentes – os seres humanos – são muito mais inteligentes e auto-reflexivas do que as formigas” (id., p. 71). As argumentações do autor e da pesquisadora citam o fato que as decisões humanas são conscientes, enquanto no caso das formigas cortadeiras, são fundamentadas basicamente em genes ou trilhas de feromônio. Além disso, as formigas não conseguem ter uma visão geral da colônia para tomadas de decisão.
No caso da comunidade de software livre, é possível analisar, sob aspectos técnicos, formas de prover visibilidade ampla entre indivíduos geograficamente dispersos – o projeto típico de software livre se enquadra neste cenário. Esta visibilidade ampla pode ser bastante significativa se considerado, por exemplo, o momento de liberação de novas versões de um produto. Tipicamente, estas novas versões são submetidas à comunidade de usuários para testes e, a partir de relatórios de problemas resultantes do uso, os programas são submetidos a correções por colaboradores de software livre – não necessariamente o mesmo indivíduo que criou o programa irá efetuar sua correção (daí a relevância das práticas de Engenharia de Software).
Conforme pode ser observado, o exemplo ilustra feedback[23], mas não implica necessariamente em visão global[24] e abre algumas possibilidades de análise:
·         Como comunicar a toda a colônia a existência de uma nova versão atualizada?
·         Como definir maneiras para um usuário não técnico proceder para identificar se, no seu caso específico, ele deve atualizar sua versão?
·         Retomando os aspectos de capacitação citados anteriormente, e sabendo que existem responsáveis por avaliar e publicar novas versões do produto: estes responsáveis teriam qualificação técnica e visão global suficiente para realizar as publicações de atualização com segurança e transmitindo confiabilidade aos usuários individuais e às empresas usuárias?
 

3. SOFTWARE LIVRE: CARÁTER POLÍTICO-SOCIAL

 

3.1 BENJAMIN: O AUTOR COMO PRODUTOR

 
A análise da produção de software livre considerando aspectos políticos remete à década de 1930, mais precisamente à conferência de Walter Benjamin pronunciada no Instituto para o Estudo do Fascismo, na qual o filósofo da Escola de Frankfurt alertava para a relevância de o autor ter autonomia e liberdade para produzir o conteúdo que desejasse. Isto faria com que esse autor fosse também um produtor.
Nesse pronunciamento, utilizando como exemplo de autor o jornalista russo Sergei Tretiakov, Benjamin afirmara que o “problema da autonomia [...] [estava relacionado à falta de] liberdade de escrever o que quiser” (BENJAMIN, 1996, p. 120), impedindo o autor de criar conteúdos passíveis de transformação social. Se “as relações sociais são condicionadas pelas relações de produção” (id., p. 122), qualquer obra que estabelecesse compatibilidade com as relações de sua época seria reacionária. Logo, qualquer autor que não fosse produtor seria utilizado pelo aparato, ao invés de utilizá-lo.
Benjamin comentou que eram poucos os jornalistas que efetivamente trabalhavam como agentes de transformação, pois os escritores eram absorvidos pelo aparato, logo, não atuavam como produtores. Na definição do filósofo, aqueles escritores que buscavam a revolução eram chamados de operativos. Destacava que para o escritor ser considerado operativo não bastava ter discurso revolucionário, mas era necessário atuar de fato com autonomia: combatendo e não apenas relatando; participando de forma ativa, e não apenas atuando como espectador (id., p. 123).
 
[...] abastecer um aparelho produtivo sem ao mesmo tempo modificá-lo, na medida do possível, seria um procedimento altamente questionável mesmo que os materiais fornecidos tivessem uma aparência revolucionária [...] [pois] o aparelho burguês de produção e publicação pode assimilar uma surpreendente quantidade de temas revolucionários, e até mesmo propagá-los, sem colocar seriamente em risco sua própria existência e a existência das classes que o controlam [grifos meus] (id., p. 128).
 
É importante avaliar se apesar de o aparato sugerir participação, na realidade, ele exerce manipulação. Utilizando ainda o exemplo do jornal, Benjamin cita o surgimento de seções (p. 124) onde ocorreria participação do leitor através de perguntas, opiniões e protestos. Estas seções, que supostamente possibilitariam a participação do leitor, apenas constituiriam um mecanismo para os redatores suprirem a impaciência diária do leitor, enquanto acreditassem estar exercendo seu direito de se manifestar.
A modificação do aparelho produtivo, na visão de Benjamin, pressupunha ainda visão não setorial, através da “superação daquelas esferas compartimentalizadas de competência no processo da produção intelectual” (id., p. 126). O conhecimento deveria ser amplo para possibilitar ao autor atuar também como produtor, gerando material crítico capaz de controlar o aparelho.
O problema da visão setorial já havia sido tratado como decorrente da divisão do trabalho em A Ideologia Alemã, quando fora classificada como alienação:
 
[...] a força produtiva multiplicada que nasce da cooperação de vários indivíduos exigida pela divisão do trabalho, aparece a esses indivíduos – porque sua cooperação não é voluntária, mas natural – não como seu próprio poder unificado, mas como uma força alheia situada fora deles, cuja origem e destino ignoram, que não podem mais dominar e que, ao contrário, percorre agora uma série particular de fases e de estágios de desenvolvimento, independente da vontade e do agir humano, e que, na verdade, digere estes últimos (MARX; ENGELS, 2006, p. 61).
 
Benjamin ainda faz uso de uma metáfora em sua conferência, quando comenta que o autor deve ser transformado de “fornecedor do aparelho de produção intelectual em engenheiro” (1996, p. 136). Evidentemente o engenheiro não é usado em seu sentido strictu sensu, mas para destacar a necessidade de um articulador capaz de transformar o aparelho, permitindo ao autor a autonomia necessária. Essa metáfora, nos anos 2000 é retomada (inclusive no nome) através da Engineering Culture[25], que discute inclusive a produção de software livre e reforça a necessidade de cuidado ao tomar o termo engenheiro proposto por Benjamin:
 
[...] o termo ‘engenheiro’ deve ser tomado em um sentido bastante amplo para se referir à atividade técnica e cultural [...] [pois] agir como um engenheiro nesse sentido, é usar o poder produtivo para possibilitar mudança e utilidade pública [grifos meus][26] (COX; KRYSA, 2005, p. 07-08).
 

3.2 CULTURA COMO ENGENHARIA: O AUTOR COMO PRODUTOR DIGITAL

 
“o sistema só seria considerado verdadeiramente emergente quando todas as interações locais resultassem em algum tipo de macrocomportamento observável. [...] A complexidade emergente sem adaptação é como os intrincados cristais formados por um floco de neve: são bonitos, mas não tem função” (JOHNSON, 2003, p. 15)
 
Na introdução da obra que atualiza o conceito de autor como produtor de Walter Benjamin para a era digital, Cox e Krysa reiteram as idéias originais do pensador alemão quando comentam que “a mudança social [ainda] não é simplesmente resultado da resistência ao conjunto de condições existentes, mas da adaptação e transformação do aparato técnico propriamente dito[27]” (2005, p. 07).
Os autores apresentam (p. 07) o contexto no qual ocorreu a conferência de Benjamin em 1934, quando havia otimismo político devido à oposição ao fascismo, e questionam se seria possível manter esse otimismo “em um momento no qual a tecnologia opera a serviço do capital de um modo muito mais insidioso [traiçoeiro][28]” (ibid.). Aqui, novamente, é possível retomar os pontos de discussão iniciais deste trabalho, para:
·         Procurar evidências que as condições de desenvolvimento de software livre possibilitam transformação do aparato de produção, e não correspondem apenas uma armadilha a serviço do capital;
·         Refletir quanto a formas de utilizar o aparato racionalmente, buscando efetiva mudança social e inclusão digital[29].
Toda esta sistematização é relevante, pois imaginar que emerge uma forma de trabalho colaborativo e de enfrentamento das grandes corporações parece simplificar em demasia um contexto complexo, que tem o aparato como centro das atenções.
 

4. CONSIDERAÇÕES FINAIS

 
“O caráter modelar da produção é [...] decisivo: em primeiro lugar, ela deve orientar outros produtores em sua produção e, em segundo lugar, precisa colocar à disposição deles um aparelho mais perfeito. Esse aparelho é tanto melhor quanto mais conduz consumidores à esfera da produção, ou seja, quanto maior for sua capacidade de transformar em colaboradores os leitores ou espectadores. [...] [Benjamim ainda cita Brecht, e comenta que] ‘acreditando possuir um aparelho que na realidade os possui, eles defendem esse aparelho, sobre o qual não dispõem de qualquer controle e que não é mais, como supõem, um instrumento a serviço do produtor, e sim um instrumento contra o produtor’ [grifos meus]” (BENJAMIN, 1996, p. 132).
 
É quase impossível conceber o cotidiano sem produtos de software, que passaram a ser parte da vida:
 
tudo passa pelas tecnologias: a religião, a indústria, a ciência, a educação, entre outros campos da atividade humana. [...] Com isso, está se gerando uma mentalidade própria da era digital em que [...] o corpo humano pelo diálogo com softwares se conecta com cérebros eletrônicos que nos levam a processos cognitivos e mentais em parceria com os sistemas (DOMINGUES, 1997, p. 17-26).
 
Neste contexto, o fenômeno comunicacional de software livre é interessante. Possibilidades de inclusão digital existem, mas considerar a atividade de programação descontextualizada das características técnicas de Engenharia de Software, além de gerar produtos com risco de resistência ao uso e qualidade limitada reduz a possibilidade de efetivamente fazer frente aos grandes produtores de software.
Considerada a produção de software apenas como criação de programas, ou para uso pessoal o problema é minimizado, mas, se o que se deseja é refletir sobre a afirmação (LEMOS, 2006, p. 61-62) que este tipo de produção colocaria em xeque o monopólio das grandes empresas produtoras de software, inclusive a gigante Microsoft, o engenheiro de software deveria ser um escritor operativo e, como tal, precisaria de posicionamento que provocasse mudança para justificar produção de software livre como resistência. Uma vez que há vantagens para o Estado na adoção de software livre por órgãos governamentais (evidentemente, desde que os produtos sejam previamente avaliados e tenham qualidade garantida), parece urgente aprofundar as pesquisas já realizadas pelo Softex[30], além de debater critérios para considerar um software livre passível de utilização por um órgão oficial.
Também é necessário avaliar formas de difundir conhecimentos sobre Engenharia de Software: de fundamental importância para que se inicie a formação de técnicos que ultrapassem os limites da programação e sejam autores que, promovidos, atuem também como produtores de software.


[1] Artigo apresentado no 4º CONTECSI (Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação), realizado na FEA/USP em Maio/2007.
[2] marquioni@marquioni.com.br – Mestre em Comunicação e Linguagens (UTP/2008) e Bacharel em Análise de Sistemas (PUC-Campinas/1994).
[3] Todas as traduções apresentadas no texto, exceto quando indicado, são de minha autoria (originais em inglês informados como nota de rodapé associada).
[4] Segundo (GNU, 2007), GNU é um acrônimo recursivo para ‘GNU's Not UNIX’ (o GNU não é o Unix) cuja pronúncia é guh-noo. O projeto GNU foi criado em 1984 com a finalidade de desenvolver um sistema operacional semelhante ao UNIX, resultado de produção de software livre. Este sistema operacional é o GNU System. O Linux, sistema operacional utilizado mundialmente, é uma variante do núcleo (kernel) do sistema GNU e sua nomenclatura rigorosa é GNU/Linux System.
[5] Open Source Initiative. Consulte www.opensource.org.
[6] Free Software Foundation. Consulte www.fsf.org.
[7] Original: “’Free software’ is a matter of liberty, not price. To understand the concept, you should think of ‘free’ as in ‘free speech’, not as in ‘free beer’”.
[8] A definição a seguir vai esclarecer que no caso de software livre não gratuito, o valor cobrado deve ser baixo o suficiente para motivar o usuário a comprar o produto, ao invés de simplesmente copiá-lo.
[9] Original: “for anyone to use, copy, and distribute, either verbatim or with modifications, either gratis or for a fee. In particular, this means that source code must be available. ‘If it's not source, it's not software’”. Conforme debate a seguir, considerando aspectos de Engenharia de Software, uma documentação adicional aos programas fonte poderia trazer benefícios, particularmente minimização de resistência ao uso e aumento na credibilidade do produto.
[10] Software proprietário “é o software que não é livre ou é semi-livre. Seu uso, redistribuição ou modificação são proibidos, requerem permissão, ou são restritos” (GNU-CATEGORIES, 2007). Original: “is software that is not free or semi-free. Its use, redistribution or modification is prohibited, or requires you to ask for permission, or is restricted”. O MS Windows é um exemplo de software proprietário, pois tem sua redistribuição proibida, além de não disponibilizar o código fonte para atualização.
[11] Original: “program must include source code, and must allow distribution in source code as well as compiled form”.
[12] Original: “It is not exactly the same class of software: they accept some licenses that we consider too restrictive, and there are free software licenses they have not accepted. However, the differences in extension of the category are small”.
[13] Além da referência GNU-Categories, 2007, uma fonte recomendável para conceitos preliminares de software livre é a dissertação de mestrado REIS, 2003 – disponível em http://www.async.com.br/~kiko/ acesso em 06/01/2007.
[14] FreewareOriginal: “has no clear accepted definition, but it is commonly used for packages which permit redistribution but not modification (and their source code is not available)”. A FSF recomenda que não seja utilizado o termo software livre para esta categoria. é um termo que “não tem definição clara aceita, mas é normalmente utilizado para pacotes que permitem redistribuição mas não modificação (e seu código fonte não é disponibilizado)” (GNU- CATEGORIES, 2007).
[15] SharewareOriginal: “is software which comes with permission for people to redistribute copies, but says that anyone who continues to use a copy is required to pay a license fee”. A FSF não considera shareware um tipo de software livre. “é software que vem com permissão de redistribuição de cópias, mas diz que qualquer pessoa que continue a utilizar esta cópia deve pagar uma taxa de licença” (GNU- CATEGORIES, 2007).
[16] Software copylefted é um “software livre cujos termos de distribuição impede que haja restrições ao redistribuir ou modificar o software. Isto significa que toda cópia do software, mesmo modificada, deve continuar sendo software livre” (GNU- CATEGORIES, 2007) – original: “Copylefted software is free software whose distribution terms do not let redistributors add any additional restrictions when they redistribute or modify the software. This means that every copy of the software, even if it has been modified, must be free software”. Em termos ideais, todo software livre deveria ser copyleft, mas “também existe software livre que é não copyleft” (GNU-PHILOSOPHY, 2007) – original: “non-copylefted free software also exists”.
[17] Software não copylefted“é um software livre que vem com a permissão do autor para redistribuir e modificar, permitindo adicionar restrições” (GNU- CATEGORIES, 2007). Original: “free software comes from the author with permission to redistribute and modify, and also to add additional restrictions to it”.
[18] Software de domínio público “é um software que não tem copyright [não tem proprietário de direitos autorais]” (GNU- CATEGORIES, 2007). Original: “is software that is not copyrighted”. Softwares sem copyright são “um tipo especial de software não copylefted” (GNU- CATEGORIES, 2007) – original: “a special case of non-copylefted free software”. “‘Domínio público’ é um termo legal que significa. ‘sem copyright’. Original: “‘public domain’ is a legal term and means, precisely, ‘not copyrighted’”.
[19] Para definições completas e exemplos de usuários individuais e empresas usuárias, assim como dados estatísticos destes tipos de usuários, consulte “O Impacto do Software Livre e de Código Aberto na Indústria de Software do Brasil” – disponível em http://www.softex.br/portal/_publicacoes/publicacao.asp?id=808 acesso em 23/11/2006.
[20] Desenvolver software vai além da escrita de código fonte. Existem atividades de Engenharia de Software que antecedem a criação dos programas propriamente ditos, sem as quais as chances de sucesso na construção de um produto seguro e confiável são limitadas – mesmo que aparentemente haja qualidade, não há garantias que o produto continuará tendo um desempenho satisfatório no tempo. Essas atividades de Engenharia de Software são também referenciadas como Processos de Software, ou Processos de Engenharia de Software. Para compreender conceitos básicos de Processos de Software, podem ser utilizadas como referência as definições propostas pelo CMMI (Capability Maturity Model Integration. Modelo de referência mundial para Qualidade e Engenharia de Software, mantido pelo SEI – Software Engineering Institute –, da Carnegie Mellon University deste 1991 (quando ainda era referenciado apenas como CMM). Este modelo define processo a partir de “três dimensões críticas [...]: [1] pessoas, [2] procedimentos e métodos, [3] ferramentas e equipamentos” (CHRISSIS; KONRAD; SHRUM, 2003, p. 4) – original: “three critical dimensions [...]: people, procedures and methods, and tools and equipment”. É relevante destacar que estas dimensões críticas, quando consideradas em conjunto estabelecem um complexo sistema comunicacional e possibilita interpretar processo como uma espécie de receita, que informa quem executa o trabalho, como esse trabalho deve ser executado e o que usar para executá-lo. Finalmente, o modelo define que “a qualidade de um sistema ou produto é altamente influenciada pela qualidade do processo usado para desenvolvê-lo ou mantê-lo” (CHRISSIS; KONRAD; SHRUM, 2003, p. 5) – original: “the quality of a system or product is highly influenced by the quality of the process used to develop and maintain it”. Para detalhes quanto ao modelo, consulte http://www.sei.cmu.edu/cmmi. Duas possibilidades de desdobramento claras deste trabalho são identificar qual é o processo adotado para desenvolver software livre e como esse processo de desenvolvimento possibilita avaliação objetiva da qualidade do produto criado (inclusive para auxiliar órgãos governamentais na adoção de software livre).
[21] Artefatos técnicos de análise e design incluem modelos de dados, modelos de classes, diagramas de casos de uso, entre outros. Como referências básicas para compreender estes artefatos, assim como sua relevância no processo de desenvolvimento de software, consultar (ELMASRI; NAVATHE, 2000), (FOWLER; SCOTT, 1999), (JACOBSON; BOOCH; RUMBAUGH, 2001), (PRESSMAN, 2000), (ROSENBERG; SCOTT, 2001), (SCHNEIDER; WINTERS, 2001), (KOTONYA; SOMMERVILLE, 1998).
[22] Uma vez que a declaração de imposto de renda de pessoa física no Brasil é realizada utilizando um software fornecido pelo Governo Federal, os contribuintes receberiam com tranqüilidade a notícia de que suas declarações de vencimentos seriam enviadas através da Internet utilizando uma ferramenta de software livre?
[23] Feedback corresponde à retro alimentação de informações, segundo a qual um sistema qualquer como, por exemplo, um sistema computacional, utiliza as saídas resultantes da execução deste sistema como informação para análise. Com isso, a saída gerada passa a ser entrada para outro sistema, ou para o próprio sistema que a originou, estabelecendo uma forma de interatividade.
[24] Em termos técnicos de software, há complexos aspectos de acoplamento e gestão de configuração envolvidos nesta operação aparentemente banal.
[25] O termo Engineering Culture será tratado neste trabalho como ‘Cultura como Engenharia’ ou ‘Cultura tratada como Engenharia’.
[26] Original: “the term ‘engineer’ is to be taken broadly to refer to technical and cultural activity […] to act as a engineer in this sense, is to use power productively to bring about change and for public utility”.
[27] Original: “Social change does not simply result from resistance to the existing set of conditions but from adapting and transforming the technical apparatus itself”.
[28] Original: “Social change does not simply result from resistance to the existing set of conditions but from adapting and transforming the technical apparatus itself. […] In the 1930s, under particular conditions and against the backdrop of fascism, a certain political optimism made social change seem more possible. Can this optimism be maintained when technology operates in the service of capital in ever more insidious ways?”
[29] Por efetiva inclusão digital pode ser entendido mais que o barateamento de computadores devido ao uso de sistemas operacionais gratuitos. Parece que fornecer o equipamento e o acesso ao conteúdo, sem fornecer conhecimento técnico completo acerca deste conteúdo, assim como de formas e potencial de utilização, caracterizam apenas uma nova forma de manipulação.
[30] Consulte http://www.softex.br.
 
 

Referências

BENJAMIN, Walter. O autor como produtor – Conferência pronunciada no Instituto para o Estudo do Fascismo, em 27 de abril de 1934. In:_____.ROUANET, Sérgio Paulo (Trad.). Obras escolhidas volume 1 Magia e Técnica, Arte e Política. São Paulo: Editora Brasiliense, 1996. p. 120 – 136.
CHRISSIS, Mary Beth; KONRAD, Mike; SHRUM, Sandy. CMMI Guidelines for process integration and product improvement. Boston: Addison-Wesley, 2003.
COX, Geoff; KRYSA, Joasia. Introdution to ‘The autor as (digital) producer’. In: _____.DATA browser 02: Engineering Culture. New York: Autonomedia, 2005, p. 7 – 29.
DOMINGUES, Diana. In: _____.A arte no século XXI: A humanização das tecnologias. São Paulo: Editora Unesp, 1997.
FSF-FS_Definition. FSF – The Free Software Definition. Disponível em: <http://www.fsf.org/licensing/essays/free-sw.html> Acesso em: 10/01/2007.
GNU. Origem: The GNU operating system: The GNU Project Free Software Foundation Free as in freedom. Disponível em: <www.gnu.org> Acesso em: 06/01/2007.
GNU-Categories. Categories of Free and Non-Free Software: GNU Project Free Software Foundation (FSF). Disponível em: <http://www.gnu.org/philosophy/categories.html> Acesso em: 04/01/2007.
GNU-Philosophy. The Free Software Definition: GNU Project Free Software Foundation (FSF). Disponível em: <http://www.gnu.org/philosophy/free-sw.html> Acesso em: 04/01/2007.
JOHNSON, Steven. Emergência: A dinâmica de rede em formigas, cérebros, cidades e softwares. Rio de Janeiro: Jorge Zahar Editor, 2003.
LAUDON, Kenneth C.; LAUDON, Jane P. Management information systems: Organization and technology in the networked enterprise. New Jersey: Prentice Hall, 2000.
LEMOS, André. Ciber-Cultura-Remix. In: ARAUJO, Denize Correa (Org.). Imagem (Ir)realidade. Porto Alegre: Sulina, 2006, p. 52 – 65.
MARX, Karl; ENGELS, Friedrich. A ideologia Alemã: A contraposição entre as cosmovisões materialista e idealista. São Paulo: Editora Martin Claret, 2006.
OPEN-Source. Open Source Initiative OSI: The Open Source Definition. Disponível em: <http://opensource.org/docs/def_print.php> Acesso em: 04/01/2007.
 

Bibliografia Complementar recomendada

 

ELMASRI, Ramez; NAVATHE, Shamkant B. Fundamentals of database systems. Reading: Addison-Wesley, 2000.
FOWLER, Martin; SCOTT, Kendall. UML Distilled: Applying the standard object modeling language. Boston: Addison-Wesley, 1999.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The Unified Software Development Process. BOSTON: Addison-Wesley, 2001.
KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering: Processes and Techniques.New York: John Wiley & Sons Inc, 1998.
PRESSMAN, Roger. Software Engineering: A Practitioner’s Approach European Adaptation. London: McGraw Hill International Limited, 2000.
REIS, Christian Robottom. Caracterização de um processo de software para projetos de software livre. São Carlos: USP, 2003. 247 p. Dissertação (Mestrado) – Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Paulo, 2003.
ROSENBERG, Doug; SCOTT, Kendall. Applying use case driven object modeling with UML: An annotated e-commerce example. Boston: Addison-Wesley, 2001.
SCHNEIDER, Geri; WINTERS, Jason P. Applying Use Cases: A practical guide. Boston: Addison-Wesley, 2001.

 
 

Congresso

Artigo apresentado no 4º CONTECSI (Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação), realizado na FEA/USP em Maio/2007.

 
 
 
 
Selecionar idioma:
 
Artigos  |  Seja um Articulista  |  Cadastre-se  |  Links  |  RSS  |  Administrar
pH Design Desenvolvido por pH Design | Copyright © 2008